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THEME  AND  OBJECTIVE 


/ 

In  order  to  realize  the  required  performance  in  the  development  of  modem  military  aircraft,  full  advantage  is 
taken  of  the  rapid  advances  in  the  computer  and  electronic  technologies.  Thusp^  each  newmircraft  design  depends 
increasingly  on  avionics,  the  overall  system  becomes  more  versatile,  but  also  more  complex. 

Modem  weapon  systems  are  being  structured  with  more  interdependency  among  subsystems.  However,  potential 
maximum  benefits  of  subsystem  and  weapon  system  development  integration  have  not  yet  been  realized. 

^iln  order  to  realize  the  benefits  of  advanced  ir  teg  rati  on  tonceptyan  domain  tain  compatible  timescales  throughout 
^-th?  subsystems  development  and  test  phases,  intelligent  mtegrated  design  concepts  and  proper  coordination  of  the 
development  program  are  essential.  "> 

New  design  and  development  strategies  should  be  considered  in  order  to  achieve  the  technical  and  performance 
benefits  expected  of  highly  advanced  and  integrated  avjooics/weapon  systems  in  an  economical  and  timely  manner. 

The  applicable^  sign  and  development  concepts  iaingconsidered-tts-  appropriate  fer  presentation  and  discussio»)An  this 
meeting  are'-aafollowsiP7 

Initiate  design  in  terms  of  overall  system  to  satisfy  operational  requirement  ■ 

-  Conduct  parallel  design  and  development  activities  in  all  relevant  disciplines 

-  Retention  of  design  and  application  flexibility  and  growth  in  subsystems  by  means  of  appropriate  data  processing 
and  subsystem  inter/intracommunications  structure  , 

-  Planning  of  logistic  support  elements  including  reliability,  maintainability  and  supportability  as  well  as  life  cycle 
cost  considerations ,  <i  r  -i 

-  Comprehensive  integrated  ground  testing  prior  to  airborne  evaluation  of  the  weapon  systems.  ^ 

The  objective  of  this  meeting  is  to  exchange  information  and  ideas  among  the  various  disciplines  involved  in 
weapon  system  design  to  the  benefit  of  integrated  system  developments  for  future  defense  programs. ''The  meeting  is 
also  expected  to  contribute  to  a  mutual  understanding  of  the  tasks  of  all  specialists  involved  in  the  realization  of 
integrated  weapon  systems. 


THEME  ET  OBJECTIF 


Afin  d'obtenir  !es  performances  requises  au  cours  du  ddveloppement  des  avions  militaires  modemes,  on  exploite 
pleinement  les  progrds  rapides  qui  caractdrisent  les  technologies  des  erdinateurs  et  des  dquipements  dlectronioues. 

Ainsi,  puisque  la  conception  de  chaque  avion  nouveau  depend  de  plus  en  plus  de  l’dlectrouique  adrospatiale,  le  systdme, 
dans  son  ensemble,  gagne  en  polyvalence  mais  voit  dgalement  s’accroitre  sa  compldxitd. 

Dans  la  structuration  des  systdmes  d’armes  modemes,  on  vise  a  une  plus  grande  interddpendance  entre  les  sous- 
systdmes.  Cependant,  tous  les  avantages  potentiels  que  Ton  peut  tirer  de  l’intdgration,  au  stade  du  ddveloppement,  des 
sous-sy stiimes  d’armes  n’ont  pas  encore  dtd  obtenus. 

Pour  profiter  pleinement  des  avantages  des  concepts  avaneds  d ’integration  et  cor.server  des  dchelles  oc  temps 
compatibles  tout  au  long  des  phases  d’essai  et  de  ddveloppement  des  sous-systdmes,  il  est  essentiel  d’avoir  des  concepts 
d’intdgration  intelligents,  au  stade  de  l’etude,  et  une  bonne  coordination  du  programme  de  ddveloppement. 


11  importe  de  prendre  en  compte  les  nouvelles  shatdgies  dt  conception  et  de  ddveloppement  pour  re  tirer  les 
bdndfices  attendus,  au  plan  de  la  technique  et  ues  performances,  des  systdmes  d’armes  et  des  dquipements  dlectroniques 
de  bord  hautement  avaneds  et  inidgrds,  de  fa;  on  4  la  fois  dconomique  et  opportune.  Les  concepts  applicables,  au  plan 
des  dtudes  et  du  ddveloppement,  qui  sont  considdrds  comme  propres  4  donner  lieu,  au  cours  de  cette  rdunion,  4  la 
presentation  de  communications  et  4  des  ddbats,  sont  les  suivants: 

-  Entreprendre  la  phase  de  conception  en  tenant  compte  du  systdme  dans  sa  totality  afin  de  satisfaire  aux  impdratifs 
opdrationnets 


Manei  paialUlc«iBv.;  Jii  iaiwdi  J’ituvle  et  4e  Ja tk  pptxer.t  Jars  tuutti  let  diK T Lina  impHqwh i 
Maintenir  la  souplesse  de  conception  et  duplication  au  n<veau  des  sous-systdmes  grace  4  un  traitement  de 
donndes  approprid  et  4  une  structure  de  communications  4  l'intdrieur  des  sous-systdmes  et  entre  ceux-ci 
khtfir  Ice  fitments  Je  suutieii  logistiquc,  y  eotnpris  It  fiabilrid,  la  lacihld  de  nrarfttcnafwe  dt  d  tppn,  aifiti  qcz  lea 


considerations  relatives  au  coOt  total  du  cycle  de  vie 

Procdder  4  des  essais  au  sol  complets  sous  une  forme  intdgrde  avant  de  passer  4  Evaluation  des  systdmes  d’armes 
dans  les  conditions  de  vol. 


Le  but  de  cette  rdunion  est  de  faire  naitre  des  (changes  d ’informations  et  d’iddes  entre  les  diverses  disciplines 
impliqufes  dans  la  conception  des  systdmes  d’armes,  pour  promouvoir  le  ddveloppement  des  systdmes  intdgrds  dans  1c 
c.idn  .Ja  futurs  prugfimrrcsdc  Jrfsnts  Celia  Ttu-.kv  Jiittii  J.-.nc  c  iniril  urr  t  accfdri  A  i  ieir  r  t  t  p-Wvujacfl 
muhuitt  H  fAtntt  rvnmbwl  1  Sow  ki  spfcSttbun*  Uttplkjst**  d*ni  k  if I'StaUun  dc  t  tytitnui  J  ’anwi  a 
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TECHNICAL  EVALUATION  REPORT 

by 

Walter  H.Vogl  and  Jesse  C. Ryles 


1.  INTRODUCTION 

The  45th  Avionics  Panel  Symposium  on  “Advanced  Concepts  for  Avionics/Weapon  System  Design,  Development 
and  Integration”  was  held  at  the  Lester  B.Pearson  Building,  Ottawa,  Canada,  from  18  to  22  April  1983.  The  meeting  was 
a  multi-panel  symposium  with  participation  of  the  Flight  Mechanics  Panel  (FMP),  the  Fluid  Dynamics  Panel  (FDP),  and 
the  Guidance  and  Control  Panel  (GCP)  of  AGARD.  The  compilation  of  papers  is  published  as  an  AGARD  Conference 
Proceedings. 


2  SYMPOSIUM  THEME 

The  theme  addressed  the  design  and  development  approaches  to  achieve  the  inherent  advantages  of  highly  integrated 
system  structures  The  increasing  interdependency  among  the  avionics  subsystems  of  modem  airborne  weapon  systems 
and  the  opportunity  to  share  information  among  these  subsystems  was  an  important  area  to  discuss  at  this  time. 

Advances  in  system  architectures,  software  development,  information  transmission  concepts,  displays,  simulation 
approaches,  etc.,  were  perceived  to  be  important  areas  to  address  in  this  symposium  to  lead  to  more  interdisciplinary 
system  design  approaches  for  future  mission  and  cost  effective  aircraft  avionics  designs. 


3.  PURPOSE  AND  SCOPE 

The  purpose  of  this  symposium  was  to  provide  a  common  understanding  of  all  disciplines  involved  in  the  airborne 
avionics  system  design.  The  participation  of  the  whole  range  of  interests  from  customers,  services,  institutes,  and  industry 
and  the  timely  discussion  which  followed  indicates  the  Program  Committee’s  aim  has  been  realized.  Discussions  were 
held  after  each  paper  and  critical  issues  opened  up  some  controversial  areas.  Although  time  was  not  sufficient  to  deal  with 
all  these  controversial  areas  in  detail,  there  was  considerable  discussion  after  the  meetings  and  during  the  breaks  by  the 
various  authors  and  observers  which  were  found  to  be  very  beneficial.  This  evaluation  will  discuss  the  concern  from  the 
viewpoints  of  use,  operational  issues  and  requirements,  state-of-the-art,  assessment  of  technology,  identification  of  pacing 
technology,  and  critical  needs  for  research  and  development,  major  challenges  and  trends;  and  finally,  provide  an  assess¬ 
ment  of  the  material  presented  and  formulate  recommendations  for  future  action. 


4.  SYMPOSIUM  PROGRAM 

The  program  of  this  symposium  was  arranged  in  four  specific  sessions  with  a  Panel  Business  Meeting  at  the  end. 

Session  I,  System  Design  Criteria,  addressed  the  overall  issues  of  weapon  system,  air  vehicle,  and  avionic  system 
requirements. 

Session  11,  Avionics  and  Systems  State-of-the-Art,  dealt  with  the  subject  of  avionic  systems  integration,  fault  tolerant 
design  approaches,  fault  detection  and  bus  structured  systems  architectures. 

Session  III,  System  Development  Concept,  considered  modeling  and  operational  analysis,  hardware  and  software 
system  design  concepts  and  hardware/software  interface  approaches/issues. 

Session  IV,  System  Integration  and  System  Test,  addressed  staged  avionic  system  integration  in  ground-based  and 
airborne  environment,  including  simulation/stimulation  and  test  facilities,  as  well  as  final  system  airborne  performance 
demonstrated. 


S.  TECHNICAL  EVALUATION 


When  the  subject  was  selected  for  this  symposium,  it  was  clear  that  it  would  not  be  possible  to  cover  each  aspect  of 
integrated  engineering  to  its  full  depth.  Rather,  it  was  the  view  to  provide  a  forum  for  exchange  of  the  various  ideas  and 
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complex  avionic  systems  forming  an  essential  part  of  the  overall  weapon  system.  After  the  four  days  of  discussion,  it 
was  noted  with  satisfaction  that  the  goal  of  the  conference  had  been  fully  met. 

The  Keynote  Address,  delivered  by  Vice  Admiral  Seymour,  US  Navy,  addressed  the  fact  that  several  basic  aspects 
have  to  be  taken  into  account  in  the  modem  engineering  business,  particularly  in  the  attempt  to  balance  between  the 
technical  feasibility  and  finanacial  affordability.  He  addressed  several  ways  as  potential  solutions  for  consideration: 
introduction  .'or  new  cost  oriented  standards;  new  avionics  systems  architecture  to  enable  fusion;  need  of  reconfigur¬ 
ability  for  easy  updating  of  both  hardware  and  software ;  and  for  the  upgrading  of  the  whole  system  after  several  years  ol 
operation.  In  summary,  the  Admiral  identified  a  threefold  challenge  for  the  engineer’s  design  work;  a  system  must  be 
operationally  available,  maintainable  and  affordable.  This  address  was  very  well  received  by  the  participants  and  is 
included  in  the  Conference  Proceedings. 

Session  1  covered  overall  weapon  system,  air  vehicle,  and  avionic  system  requirements.  The  first  paper  highlighted 
technology  advancements  in  electronics,  computers  and  software  which  had  yielded  significant  improvements  in  avionic 
subsystems.  The  second  paper  identified  operational  requirements  which  drive  weapon  control  system  design.  The  third 
paper  emphasized  the  necessity  of  implementing  operational  readiness  guidelines  in;  design  for  testability,  operational 
fault  tolerance,  diagnostics  and  self-healing,  post  flight  extraction/analysis  and  integrated  test  and  maintenance.  The 
fourth  paper  presented  a  computational  approach  available  and  utilized  by  NWC,  China  Lake,  CA  to  evaluate  the  relative 
force  level  effectiveness  of  different  technologies.  The  fifth  paper  stressed  the  need  lor  a  new  approach  to  system  design  in 
the  future  to  avoid  aircraft  from  entering  the  inventory  with  out-of-date  electronics  technology.  The  seventh  paper 
reviewed  overall  structuring  criteria  and  concepts  as  well  as  the  sensor/subsystem/software  issues  related  to  the  problem. 
The  eighth  paper  addressed  the  fact  that  the  electric/electronic  equipment  of  modem  aircraft  is,  or  will  be,  exposed  to 
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components,  and  increasing  dependence  of  modem  aircraft  on  proper  functioning  of  electronic  equipment.  The  ninth 
paper  discussed  the  six  interfaces,  i.e.,  operating/machine  interface,  software  interface,  and  four  busses  (internal,  external, 
tfvknwes  Iffy  <mkI  liisot,  defined  as  (Weowrfy  *.>  eisaf*  oftimiffl  dere-kpruciit  A  a  erc-w  sfotkm  lot  TlMfofm  applii* 
tionsof  the  1990’s  weapon  systems.  The  tenth  paper  dealt  with  an  integrated  head-up  (HUD)  and  head-down  (HDD) 
display  concept  employing  new  optical  technologies  which  promise  improved  interaction  between  the  pilot  and  weapon 
system.  The  eieve  ith  papei  attempts  to  stimulate  new  views  anu  approaches  to  die  problem  of  proper  functional  integra¬ 
tion  of  the  man  and  avionics  technical  means.  The  twelfth  paper  describes  the  elements  of  a  US  Navy  Advanced  Aircraft 
VtTur.nrvi  Vy»l«io<Vi£Fkrp  whit  ‘  10  ha**  ten:  p«rsa*d  in  only  s  Uh.iu  J  'lo^w  '!««  10  I  I Tk  M1  *  i* , Js  Itw  fail 
paper  presented  the  results  of  a  study  to  achieve  maximum  standardization  between  the  aircraft  and  external  stores  while 
minimizing;  (1 )  the  modification  studies  required  for  each  type  aircraft/store  type;  (2)  the  development  of  new  equip¬ 
ment  specification  for  each  store/aircraft  type;  (3)  the  installation  and  wiring  charges  required  for  each  new  store 
application  in  an  aircraft. 
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detection  and  bus  structured  systems  architectures.  The  first  paper  presented  the  Fighter'Attack  aircraft  of  the  future  as 
a  highly  integrated  weapon  system,  integrating  (vice  stand  alone)  function/subsystems  such  as  penetration,  target 
acquisition,  weapon  delivery,  threat  detection  and  suppression  and  flight  engine  control.  Also  discussed  were  the  issues 
relating  to  the  architecture  of  such  near-future  systems  wherein  sensor  blending/data  fusion/high  speed  operation  are  to 
be  successfully  achieved.  The  second  paper  described  in  some  detail  the  current  F/A-18  and  indicated  some  of  the 
possible  enhancements  to  be  made  on  the  aircraft  in  the  future.  The  third  paper  provided  a  detailed  look  at  the  UK 
MOD  Defence  Standard  (DfcF  STAN  00-18)  which  is  the  definitive  UK  Standard  for  digital  interfaces  in  aircraft.  The 
iouiTii  paper  was  concerned  w rtf)  rf.e  subject  of  Icclmiquts  fi  r  Wcrbiis  t’omJTiariicaTion  m  a  Mufrrbu*  Avionic  system. 
The  fifth  paper  noted  that  with  the  advent  of  M1L-STD-1 760  (Standard  Stores  Interface),  while  system  transparency  is 
preserved  with  minimal  restiictions  imposed  on  the  airframe  manufacturer,  it  would  still  be  very  difficult  to  meet  the 
standard,  physically  and  electrically,  with  discrete  wiring.  The  sixth  paper  dealt  with  the  issue  of  evaluating  network 
communication  techniques  to  arrive  at  promising  candidate  approaches  (or  1 990’s  advanced  avionics  architectures.  The 
seventh  paper  gave  a  description  of  a  microprocessor  control,  ground-based  test  set  for  the  F/A-18  aircraft.  The  eighth 
paper  dealt  with  first  level  integration  maintenance  and  armament  systems  and  described  an  integrated  maintenance 
approach  that  produced  many  advantages.  The  final  paper  was  concerned  with  computer  graphics  techniques  for  aircraft 
EMC  Analysis  and  Design  and  described  an  effective  computer-aided  system  for  prediction  of  the  potential  interaction 
between  avionics  systems  with  particular  attention  paid  in  the  paper  to  anlenna-to-antenua  coupling. 

Session  III  covered  a  broad  range  of  avionic  system  and  subsystem  integration  issues.  The  first  paper  dealt  with  the 
experiments  on  the  human  factors  aspects  of  the  display  system  for  a  television  guided  lock-on  missile  for  use  against 
gA/uiiJ  targets,  judi  as  *dK  fie  emptujed  by  the  f-ttieiw  fcepaflic  of  The  «icWTifia*sed  tiead-op  dismays, 

head-down  displays,  and  helmet  mounted  displays.  The  second  paper  outlined  the  software  development  environments 
over  the  last  twenty  years,  using  as  examples  aircraft  developed  by  British  Aerospace.  The  problems  of  rapid  growth 
of  computer  requirements  and  activities  to  address  these  problems  are  detailed.  The  third  paper  described  the  Avionic 
Systems  Demonstrator  Rig  at  Brit.sh  Aerospace  which  represented  a  complete  aircraft  system,  linked  to  an  advanced 


x 


cockpit,  appropriate  to  the  next  generation  of  tactical  combat  aircraft.  The  fourth  paper  outlined  the  development  of 
communications  and  navigation  identification  (CNl)  systems  from  the  original  concepts  which  were  just  a  collection  of 
individual  equipments,  through  to  a  concept  of  an  integrated  CNl  discussed  in  this  paper,  in  which  several  receiver- 
transmitters  are  interfaced  with  a  signal  processor.  The  fifth  paper  describes  a  computerized  technique  to  assist  in 
assessing  the  vulnerability  of  specific  delivery  tactics.  The  sixth  paper  described  and  discussed  current  technology,  i.e., 
beam  penetron  and  shadow  mask,  raster  and  stroke  writing,  and  then  continued  with  a  review  of  a  five-phase  program  of 
assessment  and  demonstration  of  advanced  technology  displays.  The  seventh  paper  described  an  approach  based  on 
weighting  the  individual  attributes  of  the  system  to  assess  the  value  of  complex  systems.  The  eighth  paper  described  the 
research  program  using  the  F-16  aircraft  to  develop  and  flight-validate  advanced  technologies  to  improve  fighter  lethality 
and  survivability.  The  ninth  paper  covered  most  of  the  avionics  and  weapon  management  aspects  of  future  aircraft, 

aitlil  ugli  Cite  lliatil  eemeeuCidUuH  Was  Oil  illc  wtapou.  lilt  tenth  papet  di&euSaed  pic-ltiTtU  auflwaiu  luoia  foi  iflt  in- 

service  support  phase  of  Tornado,  for  support  of  major  avionic  retrofits  in  general  and  for  the  support  of  the  description 
and  the  development  of  future  aircraft.  It  was  considered  that  no  completely  satisfactory  tool  existed  at  the  time; 
therefore,  to  meet  this  requirement,  CADAS  was  developed.  This  is  a  computer  aided  design  tool,  designed  to  make 
maximum  use  of  commercially  available  operating  systems.  The  eleventh  paper  dealt  with  the  need  to  study  EMC 
poAfc  i  wi  «y»i<  t.rt  fnlunphiuid  the  ikxa! It  comiJ-.T  llu  EMC  lsp^ed  fen,  the  tiuy  Icginnkii;  .1  1  pt^jc'_t, 
and  plan  manning  levels,  work  programs,  etc.  The  final  paper  described  a  program  initiated  in  1975  aimed  at  providing 
guidance  on  how  to  design  avionic  systems  for  the  1980s.  Design  considerations  included  cost,  reliability  and  maintain¬ 
ability.  The  work  led  to  the  building  of  a  demonstration  system  in  a  Cessna  402  twin-engine  general  aviation  aircraft. 

Session  IV  concentrated  on  the  demands  for  future  engineering  work:  to  develop,  provide  and  apply  computer- 
aided  integration,  simulation  and  test  methods  and  facilities  with  all  the  hardware  in  the  loop.  The  first  paper  addressed 
two  main  elements  which  helped  to  overcome  the  inherent  engineering  problems  for  integrating  such  a  complex  system: 
close  organizational  relationship  between  the  designers  and  the  users  has  to  tie  established  from  the  beginning  of  the 
project  and  the  use  of  highly  developed  simulation  and  support  devices  for  dynamic  integration  on  the  ground  and  in 
the  air.  The  second  paper  explained  the  unique  capabilities  and  design  of  the  Dynamic  Flight  Simulation  and  Crew 
Station  Evaluation  Facility  built  at  the  Nava!  Air  Development  Center  as  they  pertain  to  avionics  system  development 
and  validation  and  to  assess  the  system  design  with  the  man  in  the  loop,  in  a  flight  envelope  which  by  far  exceeds  that  of 
in-flight  simulation  or  flight  tests.  The  third  paper  reviewed  the  methods  and  facilities  applied  to  the  avionics  and 
weapon  integration  of  the  PANAVIA  Tornado  aircraft  and  then  advanced  ideas  on  how  to  evolve  these  proven  concepts 
to  more  complex  systems.  The  fourth  paper  described  hardware-in-the-loop  simulation  techniques  used  in  the  develop- 
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associated  software  were  tested,  validated,  and  integrated  into  the  aircraft.  The  fifth  paper  described  the  Northrop 
Avionics  Simulation  package  (Executive  Support  System)  which  has  been  designed  to  support  the  development  of  fault 
tolerant  avionic  systems  and  is  currently  used  for  the  F-5C,  F-l  8L  and  F-20  avionics  models.  It  provides  a  mechanism 
for  developing  and  testing  several  avionic  core  configurations  as  well  as  avionic  simulation  and  application  modules.  The 
sixth  paper  addressed  the  methods  applied  for  testing  the  PANAVIA  Tornado  Autopilot  and  Flight  Director  System 
(AFDS).  A  new  automated  AFDS  Cross  Software  Test  Sys*em  and  facility  was  presented  in  detail.  The  seventh  paper 
provided  a  summary  of  challenging  concepts  for  practically  useful,  cost  efficient,  and  automated  validation  techniques  for 
high  integrity  software.  A  promising  technique  identified  as  ‘‘symbolic  execution"  is  discussed  and  the  results  of  a 
detailed  study  are  presented.  The  final  paper  discussed  the  approaches  and  problems  associated  with  using  a  static 
atiojiii*  develop.. iciii  and  lest  .ig.  A  i.tw  dynamic  test  technique  fs  described,  the  advantages  tlluininateu  anu  its  applica¬ 
tion  to  the  Tornado  Air  Defense  Version  aircraft  outlined. 


6.  CONCLUSIONS 

lift  cXffcuittj  djffjcttl  Jut  a  feTi  people  (.■  JuTli  rotate  spcCTWC  hidings  of  S  SJ-nrpusra  with  tercft  a  tifciJ  fangs.  oK 
technical  cove. age  alid  attended  by  specialists  from  an  equally  tiTuad  range  of  interests.  Hie  principal  conclusions  irom 
the  paper  presentations  and  subsequent  questions/discussions  are  as  follows: 
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profound  effect  on  avionics  system  design,  development  and  testing  concepts/techniques. 

6  2  The  emergence  of  digital  information  coupling  among  avionics  subsystems  has  contributed  to  initial  interface 
standardization  such  that  some  degree  of  technology  transparency  exists  for  update  and  retrofit  of  avionics  subsystems. 

ft.J  AJiancciiiertWffi  trkniics  awhlfOrtmc  mrd  IrfuniHftic/n  rfiaihig  emiecpH  jftottlJ  letiJ  to  enlnurevM  ww  Kikiancc. 
on-board  diagnostics  and  performance  capability  as  well  as  reduced  logistical  support  for  future  avionic  systems. 

6.4  As  avionics  subsystems  become  more  integrated  and  highly  interactive,  more  effective  and  economical  techniques 
will  be  required  for  software  design,  development  and  testing. 

6.5  Fundamental  studies  are  needed  which  illuminate  the  trade-offs  among  avionics  system  architecture  choices  and  the 
significant  variables  of  interest  such  as: 


Weapon  system  application 
Misssion  availability 

Technology  state-of-the-art  implemented 
Fault  tolerance/diagnostic  capability 
Software  design,  development  and  test 
Logistic  supportability 
Life  cycle  cost 


7.  RECOMMENDATIONS 

7.1  The  timely  dialogue  and  interest  displayed  by  the  participants  at  this  meeting  in  avionic  system  architectures,  soft¬ 
ware  development  and  validation,  and  system  integration  and  test  suggests  that  future  meetings  should  be  of  less  breadth 
and  more  depth  of  coverage  in  each  of  these  subjects. 

7.2  Specialists  meetings  devoted  to  each  of  these  subjects  or  a  two  to  three  day  symposia  limited  to  one  or  two  of  these 
areas  would  be  a  valuable  forum  for  the  Panel  to  consider  for  future  meetings. 


ANNEX 


GENERAL  COMMENTS 


I.  SELECTION  OF  PAPERS 

Over  70  abstracts  were  received  in  response  that  called  for  papers,  some  of  which  were  received  too  late  for 
consideration  at  the  meeting  of  the  program  committee.  The  committee  had  a  difficult  task  in  selecting  approximately 
41  papers  which  were  considered  to  be  the  optimal  number  for  a  4-day  symposium,  and  was  obliged  to  reject  a  large 
number  of  the  abstracts  submitted.  The  objectives  were  to  provide  a  selection  of  high  quality  papers  for  each  of  the 
sessions  that  would  fit  well  within  the  theme  of  the  meeting  and  give  a  good  impression  of  the  range  of  interest  and 
quality  of  work  in  the  countries  participating.  The  distribution  of  papers  per  country  is  shown  below: 

2  Canada 
5  France 

7  Germany 
1  Italy 

8  UK 
18  US 

Attendance:  The  total  number  of  participants  was  217  including  panel  members.  The  National  distribution  was: 


111 

Canada 

34 

USA 

22 

W.  Germany 

21 

France 

17 

UK 

6 

Italy 

3 

Belgium 

1 

Denmark 

1 

Greece 

1 

Netherlands 

2.  LOCAL  ARRANGEMENTS 

The  symposium  was  held  in  the  Lester  B. Pearson  Building.  The  facilities  were  unanimously  recognized  as  the  best 
ever  offered  fora  AVP  meeting.  Canadian  Host  Coordinator,  Dr  MacPherson,  is  to  be  congratulated  for  his  support  and 
on  the  thoroughness  and  the  success  of  the  arrangements.  The  Canadian  National  Delegate  present  at  the  meeting  was 
Dr  D.Schofield.  Participants  were  entertained  at  an  official  reception  in  the  Lester  B.Pearson  Building.  A  technical  tour 
was  also  conducted  through  the  Satellite  Test  and  Integration  Facility,  David  Florida  Laboratory,  Ottawa. 
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KEYNOTE  ADDRESS 


by 

Vice  Admiral  E.R. Seymour 
Commander 

Naval  Air  Systems  Command 
Washington,  D.C. 

USA 


It  is  a  pleasure  to  be  here.  1  appreciate  the  kind  words  of  the  introduction.  In  the  introduction  it  was  noted  that  I 
became  an  aeronautical  engineer  in  1962.  1  would  like  to  point  out  that  this  was  in  the  area  of  propulsion,  not  avionics. 

Mr  Vogl  in  his  opening  remarks  used  the  classic  picture  of  airplanes  as  perceived  by  the  different  speciality  fields  in 
the  aeronautical  world.  The  propulsion  specialist  thinks  of  an  airplane  as  a  flying  engine  while  the  avionics  specialist 
thinks  of  an  airplane  as  a  flying  antenna.  That  is  one  of  the  reasons  over  the  last  three  years  I  have  found  it  very  useful  to 
get  out  and  talk  to  avionics  groups.  1  have  talked  to  a  number  of  avionics  groups  in  the  United  States  and  this  is  my  first 
opportunity  to  speak  to  avionics  groups  outside  the  United  States.  It  is  useful  to  spend  time  with  you  just  to  explain 
some  of  the  necessities  of  other  parts  of  the  aerodynamic  world. 

In  my  presentation  I  will  concentrate  ou  the  need  to  reduce  avionics  costs.  With  the  multibillion  dollar  budget  that 
I  have  this  year,  the  main  thrusts  that  I  feel  in  Washington,  the  pressures  on  me,  are  to  reduce  costs.  This  is  primarily 
because  we  are  now  spending  two  digit  millions  of  dollars  for  an  airplane.  When  I  started  flying  in  the  1950s  we  were 
buying  different  aircraft,  not  as  capable,  but  they  cost  less  than  a  million  dollars  each. 

If  escalated  by  inflation  only,  not  the  extra  money  spent  for  improved  capability,  we  would  certainly  not  be  up  to 
40  million  dollars  per  aircraft  which  is  where  we  are  with  some  of  our  airplanes  today.  All  the  pressure  to  reduce  cost, 
and  that  is  essentially  on  unit  cost,  is  driven  by  the  fact  that  we  cannot  buy  aii  those  systems  that  we  think  we  need. 

We  are  part  of  the  problem  in  a  way  because  we  insist  on  improved  capability,  but  1  think  you  will  see  that  to  some 
extent  we  need  to  do  that.  We  have  done  things  like  insist  on  multimission  capability  in  aircraft  in  the  United  States 
Navy.  The  F/A-18  was  our  first  example  of  one  that  was  designed  with  that  in  mind  from  the  beginning.  When  we  first 
chose  the  r-17  from  the  Air  t-orce  light  weight  fighter  competition,  the  first  step  we  took  was  to  totally  redesign  the 
aircraft  to  make  it  multimission  capable.  The  main  reason  for  that  is  that  we  were  trying  to  put  that  aircraft  on  aircraft 
carriers,  aircraft  carrier  real  estate  is  the  most  expensive  in  the  world.  I  have  heard  it  quoted  at  96  thousand  dollars  per 
square  inch.  Given  that  that  is  the  amount  of  real  estate  we  are  operating  with,  clearly  you  want  whatever  you  put  on 
that  real  estate  to  be  capable  of  doing  almost  anything. 

the  wn  w-r>  tar-kUly  jcD  ort-bearfwjlivo,  Tik*  Jo*rr>Ui",£ uur  ljr?J  uni.  a 

capable  jet  and  if  you  recall  those  days  we  gave  up  95%  of  our  ground  payload  to  go  from  propeller  to  jet  aircraft  because 
we  felt  that  the  speed  performance  was  necessary.  We  got  to  Korea  and  the  Navy  did  not  have  any  jet  aces  because  in 
those  days  of  bringing  in  the  new  technology  we  were  not  able  to  achieve  both  speed  and  maneuverability  and  still  get  the 
aircraft  on  the  carrier  in  the  early  1950s.  Well,  it  is  my  view  that  we  have  achieved  the  required  capability  now.  The 
performance  capability  and  maneuverability,  and  speed  of  the  F-14  and  F/A-18  and  the  current  crop  of  US  fighters  is 
sufficient.  There  are  other  advances  in  technology  that  we  are  pursuing,  of  course,  like  composites,  but,  in  general,  in  the 
aerodynamic  world  it  is  my  view  that,  for  the  near  term,  until  the  choice  is  made  to  make  the  quantum  jump  to 
hyper™ ni<-  vehiHpc  u/p  ha vp  Hua*  wt  rtMl  in  tirmi  uf  ieni Jy irniic  p*vfjrm*nL'1 

The  improved  performance  required  for  our  next  generation  of  aircraft  depends  on  the  threat,  what  is  available  to 
counter  that  threat,  and  the  tactics  for  employing  Naval  Air  Forces  or  Air  Forces.  In  my  view  we  are  going  to  need  major 
kist-’asM.-HV  of strao?  kvlomurilotv.  MJe  aw  wyTc-gefwfuof  4nto5Trerti^:  waiatk 

on  board  the  airplanes,  but,  even  more  so,  available  to  the  pilot  and  available  to  be  used.  The  filtering  of  that  data  is  what 
l  call  fusion;  I  have  information  available  from  a  number  of  sensors  and  somehow  I  fuse  >t  so  that  it  can  be  used  by  the 
u^rdiui  him  only  that  inijnnation  which necessary  to  accomplish  ms  job  and  it  fihcn>  ct  integrates  the  other 
input  information  to  provide  that  output  information. 

The  need  to  provide  all  this  information,  though,  can  be  expected  to  escalate  the  avionics  cost.  This  cost  increase 
per  aircraft  in  turn  set  up  a  vicious  circle  of  management  problems  which  I  have  alluded  to.  For  example,  if  the  avionics 
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in  the  weapon  system  on  an  aircraft  are  more  expensive  by  basically  a  historical  thumb  rule  you  can  expect  the  logistics 
and  flyaway  cost  of  the  aircraft  to  be  more  expensive.  The  more  costly  the  aircraft,  the  fewer  I  buy 

*1*  joiii ktl'ili-ourt,  rtfufti  opswlW  •frwsfll’  (c  w<5 

United  States  we  do  not  buy  a  stockpile  of  aircraft  and  then  use  them  gradually  until  we  get  down  to  the  minimum  force 
level  and  then  buy  another  stockpile.  We  buy  only  the  aircraft  needed  to  maintain  the  minimum  fleet  level  for  the 
current  year.  The  media  reports  that  the  attrition  aircraft,  the  aircraft  purchased  to  replace  those  lost,  cost  nearly  twice 
the  original  cost  and  this  is  essentially  true.  The  limited  quantities  that  we  are  able  to  buy  because  of  increased  costs  then 
lead  us  to  a  numerical  disadvantage  vis  a  vis  the  enemy  and  place  major  pressures  on  the  management  or  the  fleet 
commander  ana  tne  support  systems  tnat  are  supporting  the  tixed  lorce  levels  ol  aircrait.  unce  we  reacn  mat  state,  we  in 
Washington  say  we  can  reduce  that  pressure  if  we  increase  the  performance  of  the  next  system  coming  around  the  corner. 
In  other  words  -  “get  more  bang  for  the  buck”  -  get  more  performance  out  of  what  we  do  buy.  These  increased  perfor¬ 
mance  requirements  start  the  whole  cycle  all  over  again.  This  cycle  is  the  basic  United  States  Department  of  Defense 
Research  and  Development  problem. 

Twenty  years  ago  one  third  of  our  aircraft  costs  was  avionics.  Today,  avionics  are  two  thirds  the  aircraft  cost. 
Twenty  years  from  now  we  cannot  have  all  the  aircraft  costs  in  avionics.  I  have  talked  about  the  cost  of  avionics  systems 
having  gone  up  as  though  it  were  bad  in  itself  and  I  do  not  want  to  leave  that  impression.  There  are  a  number  of  people 
in  'i  Viiugki  i  "I  i  £  k  i*.  U,J  - w-j  I'W  t*  it!  i.-*5  tc  u  5  tfubgCt  *  V  cuttt  » -»•  afentlV.  f  .P.J  Ur- 

capabilities  have  gone  up  tremendously.  In  World  War  II  we  probably  had  no  more  than  50  pilots  that  regularly  flew  at 
night  off  carriers  and  that  was  towards  the  end  of  the  war.  In  the  early  50s  we  had  a  number  of  operational  days  when 
we  did  r.ot  fly  because  the  weather  was  too  bad.  Today,  normally,  if  there  is  an  operational  need,  carriers  will  launch  in 
any  weather.  The  aircraft  can  return  in  zero-zero  weather  conditions  if  everything  is  working  properly.  The  A-4C  that  1 
started  flying  in  1965  in  Vietnam  had  a  simple  navigation  system  and  no  bombing  system  at  all.  The  A-4Es  that  1  flew 
tne  next  year  had  prooabiy  tne  first  generation  cf  a  computer  aiaeo  bombing  system  ana  it  was  tremendously  neipfui 
to  those  of  us  dropping  bombs  at  the  time.  I  was  the  project  manager  when  the  A-7  was  introduced  in  1970.  The  A-7E 
■ww  w fjr*i  lit*  -  rtTwit  airenPl  a  "  w:  MPf  A’A; 

With  a  weapon  system  like  the  A-7  we  can  send  a  pilot  out  and  on  the  first  pass  on  a  strange  target,  he  can  roll  in  and  get 
the  bomb  within  50  feet  of  the  target.  That  is  fairly  impressive  having  flown  the  A-4C  early  in  my  career.  With  the  A-4C, 

if  yvu  ivl,wi  v  lli„  latgvla  wtTc,  welt  awv.udiCiA^d  iu  itii.  patVeIh,  m id  wcic  ati it  luhwtp  ll  t  aiTSpvbd  ufivicT  vulillui, 

you  could  probably  get  the  bomb  150  feet  from  the  target. 

Though  coupled  with  improved  performance,  avionics  has  been  the  significant  factor  in  the  growth  of  military 
iilvTdB  105IS.  1  nefo  aft  Very  tew  Times  in  tU  guVcriiimuT  lift  cycle  wlicu  it  can  aft  jld  To  pay  To  fccT  a  certain  j/cfftu- 
mance  no  matter  what  i'ne  cost.  Typically,  wars  tend  to  be  one  of  these  times.  Peace  is  not  one  of  these  times;  it  should 
not  necessarily  be  one.  I  am  not  suggesting  that  it  should  be.  One  of  the  major  points  I  would  like  to  make  at  this 
AGARD  Avionics  Panel  Symposium  is  that  you  should  not  be  primarily  interested  in  more  performance  from  avionics 
independent  of  costs.  Costs  have  to  be  one  of  your  drivers.  It  is  one  of  the  government’s  drivers  and  it  is  probably  one 
nfyouf  comm  "trial  LijnSi  irn.r'*  Uriftn  Tiflujtusli  !  ■:  B*if  i  Tii :  i*  tTi>  Litl  in  rti«  rs*.  ilv  foyenmr.'nl  wha.  w,  -r.- 
using  taxpayers  money  to  buy  a  requirement,  it  is  incumbent  upon  us  -  and  pragmatic  politics  demands  it  -  that  we 
trade  off  performance  for  reduced  costs.  The  improved  performance  needed  for  the  next  generation  of  aircraft  must  be 
■cMetstf tiH;  m  tiff-  fdat-te  s«*l  cf  w  will!  ef.aW  itfcsAiLg.  TLv 4h.p»o*t0 -pellm  .,hr  wM bt  *  nive  ttnrrg bw 

no  one  could  afford  it.  1  have  been  emphasizing  the  need  to  reduce  procurement  costs  of  avionics,  but  the  reduction  of 
the  life  cycle  costs  for  maintenance,  depot  overhauls,  and  systems  spares  should  also  be  understood  as  included  in  the 
need  Iu  develop  affu.udulc  diiuiuca  systems,  uivc.t  ifiaT  the  coal  of  avionics  is  a  pioVltm,  wlidt  can  we  Jo  auuut  iu 

This  symposium  is  useful  because  you  are  going  to  look  at  new  avionics  concepts  and  solutions.  We  have  thought  in 
the  past  of  ways  to  solve  this  problem,  we  have  made  efforts  right  along  to  reduce  costs.  Where  should  we  go  from  here? 
Should  we  go  to  more  Very  Large  Scale  Integrated  Circuits  (VLSlC)?  As  you  know,  we  have  an  R&D  program  in  the 
United  States  for  Very  High  Speed  Integrated  Circuits  (VHS1C)  and  a  number  of  us  think  this  is  very  attractive.  I  can  see 

Suirn.  gTall  CaflcflTS  To  it.  ltUS  is  a  AckI  trttli  5  iftfhun  ftlaT  15  <nTv.ad}  ill  IcDCtnvli  aufl  devd  jpThetA.  CjThllJfty  speaking, 

the  cost  of  avionics  historically  can  be  measured  as  a  function  of  its  weight.  Increase  the  number  of  black  boxes,  the 
costs  of  avionics  goes  up;  increase  the  density  of  avionics  and  the  costs  go  up.  VLSlC  and  VHS1C  both  promise  some 
major  advances  aiong  wnh  digital  optics  and  fiber  optics,  i.e„  if  we  really  let  them,  they  can  drive  down  die  size  ol 
avionics.  History  will  tell  you  that  if  we  have  20  cubic  inches  available  on  an  airplane  someone  will  find  a  way  to  fill  it  up 
and  will  probably  fill  it  up  with  more  dense  equipment;  this  means  costs  will  go  up.  Well,  while  I  think  these  things  are 
useful  in  the  near  term,  what  I  really  would  challenge  you  with  is  a  far  term  concept.  It  could  still  be  done  in  five  years, 
but  what  needs  to  be  done  is  to  start  thinking  about  it  now  because  a  lot  of  people  would  say  that  if  we  make  it  lighter 
we  will  have  more  space  and  we  will  add  some  more  sensors.  How  about  standards?  Well,  the  Navy  has  been  leading  the 
government  in  attempting  standards.  The  thought  is  that  if  we  had  standards  we  will  probably  get  production  cost 
efficiencies  in  the  economies  of  scale.  One  could  raise  the  question  do  we  really  save  money,  do  we  really  gain,  or  do  we 
block  innovation?  I  would  have  to  vote  that  we  block  innovation.  Standards  are  beneficial  during  production.  The  trend 
that  shows  avionics  costs  increasing  indicates  that  standards  do  not  seem  to  be  the  only  answer. 

LtlgiiAi  muftipiexi:ig  LustS  fKL  X  tutSt.  )  an  fn-W  ill  a  (A  airplawcs  alia  Icing  nii-KiVUu  Tin  1>  JtffiCT  all piaiies. 

This  provides  better  communication  between  black  boxes  and  better  capability  to  upgrade  boxes  over  the  near  term,  but 
it  still  leaves  the  black  boxes.  The  challenge  might  be  an  entirely  new  avionics  systems  architecture.  I  will  be  the  first  to 
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tell  you  that  I  do  not  know  how  to  do  this.  But  it  really  is  something  that  is  necessary  in  research  and  development  and 
would  l-  a  piae-  ferteseattfc1  and  Jk-Vtlopinwid  iu  at.  Wat  it  bright  Ju  would  be  t;  ptuvide  a  quaiiim..  jui..p 
towards  the  state-of-the-art  in  advanced  integrated  avionics  systems.  As  1  mentioned  before,  a  new  avionics  systems 
architecture  needs  to  provide  the  fusion.  Somehow,  the  military  side  of  development  needs  to  start  rethinking  logistics 
if  you  could  get  a  total  radar  on  a  single  IC  board.  We  do  not  have  this  yet,  but  we  have  to  start  rethinking  because  we 
cannot  go  out  and  buy  spares  after  the  system  has  already  been  built.  Avionics  systems  will  be  more  software  intensive. 
We  must  be  more  adept  or  more  knowledgeable  in  updating  or  correcting  software.  An  example  1  use  is  the  F/A-18 
Right  Test  Program  to  modify  the  software  we  needed  for  the  flight  control  laws.  We  planned  to  do  this  in  one  month. 
The  first  two  times  we  did  it  took  us  six  months  each  at  least  This  should  have  been  no  sufi  rise  but  we  did  not  ;-lan  it 
that  way.  A  challenge  for  the  future  is  that  you  must  demonstrate  to  those  reviewing  your  work  that  you  have,  in  fact, 
considered  cost  or  the  economic  realities  as  a  part  of  your  total  design.  These  kinds  of  questions  are  traditionally  asked 
ani.aaily  wi.tu  1  g_  to  Congress  h,  J  -fan J  the  budget.  Fl.i:  kg_hig  l_  bt  s  JtefuMr.iy  wow.  t  am  going  L  Ul  you  that 
we  need  to  do  evolutionary  vice  revolutionary  changes.  Evolutionary  aircraft  is  the  way  to  update  airplanes.  What  I 
have  thrown  into  your  laps  this  morning  is  the  challenge  that  a  revolutionary  invention  such  as  new  avionics  architecture 
is  very  hard  to  sell  because  it  is  revolutionary.  It  will  take  a  lot  of  testing  and  product  proving  to  show  that  it  really  was  a 
good  invention. 

In  conclusion,  regardless  of  the  degree  of  technological  advancements  the  future  of  avionic  design  and  architecture 
may  bring,  the  system  must  be  operationally  available  and  maintainable  in  the  field  and,  as  1  have  emphasized  for  Tie  last 
thirty  minutes  it  must  be  affordable. 
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SUMMARY  OF  SESSION  ! 
SYSTEM  DESIGN  CRITERIA 

by 

J.C.  Ryles 
Session  Chairman 


This  Session  was  organized  to  address  the  overall  issues  of  Weapon  System  Requirements,  Air  Vehicle  Requirements 
and  Avionic  System  Requirements. 

Paper  number  one  entitled  “System  Architecture:  Key  to  Future  Avionics  Capabilities”,  by  Mr  G.R. England, 
Director,  Avionic  Systems  Department,  General  Dynamics  Corporation  was  arranged  to  be  a  keynote  or  theme  setting 
presentation  for  this  session.  Mr  England  highlighted  technology  advancements  in  electronics,  computers  and  software 
which  had  yielded  significant  improvements  in  avionic  subsystems.  He  pointed  out  how  independent  advances  in 
technology  has  not  yielded  the  system  functionality  required  and  resulted  in  complex  developments  with  higher  spares 
and  life  cycle  costs.  He  presented  a  challenge  for  the  future  to  depart  from  past  and  current  system  design  practices.  He 
advanced  the  proposal  to  work  in  concert  the  areas  of  physical,  functional,  information  exchange  and  system  control 
architectures  while  employing  standard,  self-testing  modules  to  arrive  at  performance  and  low  life  cycle  cost  objectives  for 
future  systems. 

The  second  paper  was  entitled  “Tactical  Requirements  Impact  on  Integrated  Avionics/Weapon  System  Design”,  by 
Messrs  J.F. Patton  and  T.Spink  of  Westinghouse  Electric  Corporation.  Mr  Spink  presented  the  paper,  identifying 
operational  requirements  which  drive  weapon  control  system  design.  He  emphasized  the  air-to-ground  weapon  delivery, 
battlefield  interdiction  mission  outlining  the  design  requirements  for  an  integrated  attack  system.  Conclusions  were 
advanced  regarding  the  best  technology  path  for  pursuit  to  yield  a  weapon  control  system  that  assures  a  high  probability 
of  multiple  target  kills  per  pass  and  maximum  survivability. 

The  third  paper  was  entitled  “Operational  Readiness  and  Its  Impact  on  the  Avionic  System  Design",  by  Messrs 
J.F.lrwin  and  K. A. Short  of  the  Northrop  Corporation.  Mr  Irwin’s  presentation  emphasized  the  necessity  of  implementing 
operational  readiness  guidelines  in  design  for  testability,  operational  fault  tolerance,  diagnostics  and  self-healing,  post 
flight  extraction/analysis  and  integrated  test  and  maintenance.  A  managerial  and  technical  roadmap  for  incorporating 
operational  readiness  goals  in  the  next  generation  fighter  was  reviewed. 

Paper  number  four  by  Mr  R.T.Haven  and  Dr  M. Cartwright  of  the  US  Naval  Weapons  Center  was  entitled  “Avionics 
Concept  Evaluation  at  the  Force  Level”.  Dr  Cartwright  presented  the  computational  approach  available  and  utilized  by 
NWC,  China  Lake,  CA  to  evaluate  the  relative  force  level  effectiveness  of  different  technologies.  The  methodology  for 
augmenting  ihe  data  base  uutizeu  with  relevant  technology  aunnutes  important  to  ru.ure  designs  was  discussed. 

The  fifth  paper  was  entitled  “A  Future  System  Design  Technique  Based  on  Functional  Decomposition.  Supported 
S  QawfW&iUe  Duslgit  Hints  arid  Cwflelltes  Mhttnwmi  C  oite"  tyj  V1+  D.AJWlfttAd  and t*  L.lfchlwr*  d  tl* 

UK  Royal  Aircraft  Establishment.  This  presentation  stressed  the  need  for  a  new  approach  to  system  design  in  the  future 
to  avoid  aircraft  entering  the  inventory  with  out-of-date  electronics  technology.  Functional  design  was  proposed  as  an 

approach  To  avoid  the  coiiCciiliaTioo  u.i  liaidwaic  solutions  too  Ca.'o  m  Hit  devclo^mci.T  oydc.  Methods  oi  pioduci.ig 

functional  designs  were  illuminated  and  experience  to  date  with  the  approach  summarized. 

Paper  number  six  was  withdrawn  from  the  program  with  insufficient  time  to  make  an  appropriate  substitution. 

Paper  number  seven  was  entitled  “A  Modular  System  Structure  for  the  Requirements  of  the  Application",  by 
Mr  P.Catel  of  Electronique  Serge  Dassault.  This  Paper  reviews  overall  system  structuring  criteria  and  concepts  as  well  as 
the  sensor/subsystem/software  issues  related  to  the  problem.  System  structuring  approaches  developed  up  to  the  early 
198U  time  frame  with  the  contemporary  computer  memory  limits  are  outlined.  A  new  system  structuring  approach  is 
rlliliiiwil  nftick  tirtwH acuity  a-l&pft  Ih*  cofnputi'f  ttAtw.'IfrirffiH  u&h  like  rrcMibt  d  *■>  aliiuti'w.  Hr  tytfcai 
structure. 

The  eighth  paper  by  Mr  D. Jaeger  of  Messersehmitt-Bdlkow  Blohm  GmbH  was  entitled  "Increasing  Significance  of 
Electromagnetic  Effects".  The  presentation  indicates  that  the  electric/electronic  equipment  of  modem  aircraft  are  or  will 
be  exposed  to  greater  electromagnetic  stress  due  to  the  use  of  fiber  composite  materials,  increasing  susceptibility  of 
modem  electronic  components,  and  increasing  dependence  of  modem  aircraft  on  proper  functioning  of  electronic  equip¬ 
ment.  Existing  specifications  are  cited  as  not  adequate  and  suggested  solutions  offered. 
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The  ninth  paper  was  entitled  "Avionics/Crew  Station  Integration",  by  Mr  W.G.Mulley  of  the  US  Naval  Air 
Development  Center.  The  six  interfaces  defined  as  necessary  to  ensure  optimum  development  of  a  crew  station  for  multi¬ 
platform  applications  of  1990’s  weapon  systems  were  discussed.  These  interfaces  included  operator/machine  interface, 
software  interface  and  four  busses  (internal,  external,  avionics  bay  and  video).  A  discussion  is  also  provided  of  the 
relevant  issues  in  the  areas  of  weapon  system,  system  development,  production,  operational  and  support  costs. 

rapt.  iiumoti  ten  by  Madame  b. Simon  oi  Avions  Marce)  Dassault  was  entitled  A  Concept  Tui  hitegiatioii  01  Ittau 
Up  and  Head  Down  Displays”.  This  paper  dealt  with  an  integrated  head-up  (HUD)  and  head-down  (HDD)  display 
:  uttuft  ran*  ixtiusfa  .  lit  in*-  -  .  -h  ik.  ,»l  •  u  1  w  n, 

system.  The  paper  advances  several  benefits  from  this  concept.  First,  it  will  considerably  ease  the  pilot  transition 
between  HUD  and  HDD.  Secondly,  the  concept  of  a  “transparent  instrument  panel”  will  enable  very  low  level  flight 
paths  and  permit  high  angle  approaches  to  be  accomplished.  General  benefits  include  increased  field-of-view  and  larger 
quantity  of  displayed  information. 

'lne  eievemn  paper  was  entitled  louiuennes  anu  c  rueria  tor  tne  functional  imegradon  o.  Avionic  Sysiems  with 
Crew  Members  in  Command”,  by  Mr  F.W.Broecker  of  the  Federal  Agency  for  Military  Technology  and  Procurement, 

W  German?  TM&pspet  *****  tzAagWGM 

of  the  man  and  avionics  technical  means.  It  outlines  the  operational  and  work  environment  for  the  crew,  discusses  several 
system  approaches  and  describes  guidelines  and  criteria  used  therein.  A  draft  of  Guidelines  and  Criteria  is  proposed  for 

uiotUSS.vli  Wittiu.  .  iLAItc  aim  tsmtllucaj  cuAllilimlTy  m  gviltlat. 

Paper  number  twelve  was  entitled  “Navy’s  Advanced  Aircraft  Armament  System  Program  Concept  Objectives”,  by 
Messrs  T.M.Leese  and  J.F. Haney  of  the  US  Naval  Weapons  Center.  This  paper  describes  the  elements  of  a  US  Navy 
Advanced  Aircraft  Armament  System  Program  which  to  date  have  been  pursued  in  only  a  limited  degree  due  to  a  lack 
of  funding.  Deficiencies  in  past  armament  systems  are  discussed  and  related  to  the  requirements  of  future  systems.  This 
ditMOMn  i  up  tolktaito  « tJ  t'n  MMch  lo  b  Ixny  puVti r» hitk'ii^ 

rational  standards  are  suggested  to  lower  cost  growth,  promote  interoperability  and  meet  support  objectives.  An 
Advanced  Stores  Management  System  Laboratory  under  development  is  described.  The  current  program  is  stated  to  be 
directed  towards  Joint  Nat  y,  Air !  otcv  dcrek/pmcM  J  MAL-STb-THu  iAfteraft  JdetVtinfl  Vn^Tti/in^ttiDA  SyvtcinV 


The  last  paper  in  Session  I  was  entitled  "Aircraft  and  External  Stores  Interface”,  by  Messrs  C.Connan  and  M.Salaiin 
uf  U»t«J  Hewuli  Ttid  i~|ir;wiMi*ttit  11  iiltii  htw.i 

the  aircraft  and  external  stores  while  minimizing  ( 1 )  the  modification  studies  required  for  each  type  aircraft/store  type ; 
(2)  the  development  of  new  equipment  specifications  for  each  store/aircraft  type:  and  (3)  flic  installation  and  wiring 
changes  required  for  each  new  store  application  to  an  aircraft.  The  issues  related  to  the  evolution  and  interface  of  various 
store  types  is  discussed.  Requirements  are  reviewed  and  certain  tradeoffs  briefly  given.  A  proposed  architecture  is 
presented  and  compared  to  STANAG  3837. 
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SUMMARY 

Since  World  War  II,  the  capability  of  avionics  has  improved  dramatically  —  but  the  ways  in  which  we 
design  and  support  avionics  have  changed  very  little.  Similarly,  the  crew  interface  with  the  system  is 
largely  unchanged.  Modern  aircraft  still  rely,  as  old  World  War  II  aircraft,  upon  the  pilot  or  crew  for 
integration  of  information  from  diverse  discrete  subsystems,  sensors  and  weapons.  During  this  long  period 
of  technology  time,  each  generation  of  systems  has  generally  (1)  become  more  complex  and  (2)  increased 
the  quantity  and  rate  of  information  to  the  crew.  In  many  weapon  system  implementations,  these  two  factors 
have  resulted  in  increased  problems  in  the  areas  of  system  availability,  affordability,  supportability  and 
operability.  Although  the  F-16  has  broken  this  trend  it  is  still  evident  that  new  system  architectures 
will  be  needed  as  mission  requirements  in  the  future  create  added  system  demands.  Traditional  avionic 
design,  support  and  operability  approaches  will  be  unable  to  cope.  The  size  reductions  and  performance 
improvements  resulting  from  large  scale  and  high  speed  integrated  circuits  will  make  it  possible  to  re¬ 
structure  the  way  avionics  systems  are  designed.  For  example,  standard  modules  for  multi-use  applications 
will  be  possible.  These  modules  can  become  the  building  blocks  for  a  new  type  of  system  architecture. 
Advanced  data  switching  communication  techniques  will  provide  the  necessary  data  transfer  rates  to  support 
sensor  fusion,  cockpit  automation,  and  fault  tolerant  processing.  Generic  signal  processors  will  make 
shared  functions  realizable.  On-line  self-tests  consisting  of  on-chip  and  special  self-test  chips  will 
make  100X  tests  at  the  airplane  level  possible.  This  in  turn  will  allow  direct  module  replacement  at  the 
airplane  level  and  will  largely  eliminate  the  need  for  extensive  support  facilities,  allowing  aircraft  to 
remain  available  for  the  completion  of  missions. 
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BACKGROUND  AND  FUTURE  PERSPECTIVE 


Modern  military  aircraft  will  require  significant  increases  in  performance,  availability  and  support- 
ability  to  meet  the  increased  threat  in  an  affordable  fashion.  Advances  in  computer,  software  and  electronic 
technologies  have  been  and  are  being  made  to  achieve  these  increases.  Avionic  developments  during  the  past 
A0  years  have  been  characterized  by  significant  advancements  in  electronic  devices  —  from  analog  elements 
to  transistors,  to  integrated  circuits  and  now  into  VLSI.  Similarly,  improvements  in  software  function 
have  been  made  in  individual  subsystems.  However,  while  devices  and  software  have  shown  significant  indi¬ 
vidual  improvement,  the  system  level  design  and  support  of  avionics  has  changed  very  little  (reference 
Figure  1).  Avionic  systems  are  still  characterized  by  distributed  functions  with  each  function  or  limited 

groups  of  functions  contained  within  discrete  DRAMATIC  ELECTRONIC  ADVANCES  IN  PAST  A0  YEARS 

individual  boxes  with  the  pilot  as  the  system 

integrator.  This  system  concept,  which  has  “  HOWEVER  - 

persisted  independent  of  advancements  in  tech-  ST1LL  DISCRETE  SUBSYSTEMS  WITH  DISCRETE  INDIVIDUAL  BOXES 
nology,  has  resulted  in  complex  develop¬ 
ments,  high  spares  costs,  less  than  optimum 
functionality  and  high  life  cycle  costs. 


Tomorrow' 8  missions  will  require  sensor 
fusion,  cockpit  automation  and  coupled  sys¬ 
tems.  Subsystems,  working  together,  will 
provide  enhanced  capability  and  increased 
tolerance  to  individual  subsystem  failure. 


The  role  of  the  pilot  will  need  to  change 
in  future  aircraft  from  that  of  a  system 
operator  and  integrator,  to  that  of  a  sys¬ 
tem  manager.  The  pilot  should  be  able  to 
express  goals  and  intent  of  operation  while 
the  system  should  integrate  the  various  sub¬ 
systems  and  sources  of  data  to  accomplish 
that  intent.  Only  in  this  manner  will  the 
weapon  system  be  able  to  remain  coordinated 
and  effective  in  the  face  of  the  increasing 
functionality  and  complexity  required  to 
meet  the  increasing  threat.  The  total  air¬ 
craft  system  will  include  the  pilot,  the 
avionic  sensor  and  the  computational 
capabilities  —  each  in  its  most  effective 
role.  Allowing  the  pilot  to  act  as  a  system 
manager  will  require  the  system  to  have 
adequate  artificial  intelligence  to  be  able 
to  make  routine  decisions,  and  decisions 
which  rely  upon  large  quantities  of  quanti¬ 
tative  data,  on  its  own.  Pilot  training  FIGURE  l.  DESIGN  AND  SUPPORT  OF  AVIONICS  HAS  CHANGED  VERY 

requirements  will  change  since  the  need  for  LITTLE  SINCE  WORLD  WAR  II 
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the  pilot  to  remember  large  quantities  of  technical  operation  details  will  be  replaced  by  training 
in  military  strategy  and  combined  avionic  system  operation.  This  new  training  regimen  will,  incidentally, 
be  much  more  transparent  to  aircraft  type  and  detailed  subsystem  configuration  allowing  much  more  rapid 
development  of  pilot  proficiency  in  new  aircraft  types. 

Future  sensor  implementations  will  need  to  be  complementary.  Improvements  in  individual  sensor  raw 
data  will  not  be  adequate  to  provide  the  desired  levels  of  detection  ranges,  accuracy,  resolution,  etc. 
Rather,  it  will  be  necessary  to  integrate  the  data  from  many  discrete  sensors  to  obtain  maximum 
benefit  from  their  individual  characteristics.  Without  such  integration,  or  fusion,  of  available  data  the 
best  system  answers  would  not  be  obtained  and  the  pilot  would  not  be  able  to  manage  the  increasingly  com¬ 
plex  system. 

The  key  to  achieving  these  future  avionic  capabilities  is  the  system  architecture.  If  conventional 
system  design  concepts  are  followed,  the  desired  added  capabilities  will  increase  system  complexity  and 
will  continue  a  long  term  adverse  downward  trend  in  supportability  and  affordability.  The  challenge  will 
be  to  incorporate  these  improved  capabilities  while  at  the  same  time  improving  supportability  and  avail¬ 
ability  and  while  reducing  costs. 

ADVANCED  SYSTEM  ARCHITECTURE 

The  desired  future  system  capabilities  can  be  achieved  with  current  and  emerging  hardware  technology 
and  with  an  extension  of  currently  developing  software  and  system  design  approaches.  Several  key  advances 
that  make  this  possible  are: 

1)  Low-Cost,  Single-Chip  Digital  Processors 

2)  High-Speed,  Single-Chip  Digital  Multiplex  Terminals 

3)  Single-Chip  High  Density  and  High  Speed  Technology 

-  Computer  Memories 

-  Standard  Interface  Test  Chips 

-  Standard  Functions 

4)  Artificial  Intelligence  Software 

5)  Intent  Driven  Design  Approaches 

For  the  hardware  elements,  a  key  to  these  capabilities  is  size  reduction.  As  size  shrinks,  bringing 
reductions  in  cooling  and  less  requirements  for  power,  it  becomes  evident  that  the  opportunities  for 
implementation  of  common  hardware  can  become  a  reality.  For  example,  the  size  of  a  MIL-STD-1553  digital 
multiplex  terminal  has  shrunk  from  three  5"  x  7"  electronic  cards  in  1976  to  a  single  5"  x  7"  card  today 
and  will  shrink  to  a  single  4"  x  5"  card  by  1984.  The  next  step  will  reduce  the  size  of  such  a  terminal 
to  a  pair  of  integrated  circuit  chips.  Given  a  standard  module  package  and  standard  casings  and  fittings, 
all  avionic  equipment  could  then  utilize  the  same  multiplex  terminal  hardware. 

In  the  software  area  a  similar  revolution  is  occuring.  Relatively  inexpensive  and  powerful  hardware 
is  allowing  the  development  of  computers  with  'reasoning'  capabilities,  able  to  evaluate  alternatives  and 
make  value  Judgements.  The  ability  to  do  this  is  allowing  new  perceptions  of  the  relative  roles  of  the 
computational  system  and  the  pilot  in  modern  aircraft.  Artificial  intelligence  approaches  have  already  been 
successfully  applied  in  other  fields  -  what  remains  is  the  application  of  those  approaches  to  avionics.  Im¬ 
proved  hardware  and  software  can  be  combined  to  achieve  the  architectural  improvements  which  are  necessary 
to  achieve  future  goals.  Several  architectural  areas  must,  however,  be  treated  in  concert  to  achieve  the 
decisive  improvements  required.  These  aress  are: 

-  The  Physical  Architecture 

-  The  Functional  Architecture 

-  The  Information  Exchange  Architecture 

-  The  System  Control  Architecture 


THE  PHYSICAL  ARCHITECTURE 

Future  avionic  systems  should  be  composed  of 
standard,  self-testing  modules  located  in  integrated 
avionic  system  racks.  Analysis  of  various  types  of 
svionic  systems  hss  shown  thsr  identicsl  types  of 
functions  are  performed  in  many  diffferent  systems 
and  in  different  parts  of  the  same  systems.  Figure  2 
shows  how  this  commonality  of  functions  is  shared 
between  a  group  of  five  aircraft  systems.  An  unusual 
combination  of  systems  has  been  selected  to  dramatize 
the  commonality  of  functions  even  among  diverse  sys¬ 
tems.  If  the  more  conventionsl  avionic  systems  are 
added  to  the  list,  the  same  sharing  of  function  types 
is  also  observed. 

In  today's  avionic  designs,  each  of  these  common 
functions  is  performed  by  a  unique  hsrdware  design.  Typically,  different  vendors  will  provide  different 
hardware  even  though  the  functions  are  identical.  This  situation  exists  because  current  designs  emphasize 
Line  Replaceable  Units  (circa  World  War  II)  rather  than  functions.  On  the  other  hsnd,  if  standard  inter¬ 
faces  and  packaging  are  adopted  (as  is  possible  with  a  unified  totsl  architecture),  it  becomes  practical 
to  design  common  functional  modules  for  multi-use  applications.  These  modules,  plus  unique  sensor  snd 
effector  interface  modules,  then  become  the  building  blocks  for  a  new  type  of  system  architecture.  Virtually 
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FIGURE  2.  COMMON  FUNCTION  TYPES  ARE  SHARED  BY 
DIFFERENT  SYSTEMS 
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any  type  of  system  function  can  be  built  from  these  modules  together  with  suitable  software.  Because  the 
common  module  types  will  be  used  in  many  different  applications  it  will  be  cost-effective  to  develop  special 
integrated  circuit  chips  and  to  implement  unique  production  methods  to  permit  such  modules  to  be  manu¬ 
factured  in  large  quantities  at  low  cost. 


Figure  3  contains  a  general  description  of  one  such  module  and  lists  some  of  the  more  important  fea¬ 
tures.  Such  a  computer  module  is  currently  feasible  using  the  MIL-STD-1750A  processor  chip  set  being 
developed  by  the  F-16  program.  Other  modules  of  the  family  would  be  of  similar  construction.  Modules  of 
the  type  shown  in  Figure  3  will  be  physically  protected  from  the  flight-line  environment  to  which  they  will 
be  exposed.  The  modules  will  become  the  Line  Replaceable  Units  (LRUs)  and  therefore  must  be  designed  ac¬ 
cordingly.  Current  module  or  card  design  approaches  will  not  suffice. 


FIGURE  3.  TYPICAL  COMMON  COMPUTER  MODULE 
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FIGURE  4.  ACROSS-THE-BOARD  BENEFITS 


Direct  module  replacement  at  the  aircraft  level  will  be  a  major  logistic  benefit  of  the  new  physical 
architecture.  To  achieve  this  goal,  an  integrated  rack  packaging  will  be  used  in  place  of  existing  LRUs. 
Racks  similar  to  that  shown  in  Figure  4  will  permit  ready  access  to  individual  modules.  Many  of  these 
common  integrated  racks  will  be  used  throughout  the  airplane  and  can  be  larger  or  smaller  depending  on 
application.  The  rack  sections  will  be  separately  removable  from  the  aircraft  to  permit  back-plane  repairs 
or  modifications.  Compared  to  current  avionics,  these  repairs  should  be  very  infrequent,  since  the  racks 
will  reduce  the  stress  on  connectors  and  will  greatly  minimize  interconnections  when  full  multiplex  communi¬ 
cation  is  implemented  between  modules.  Individual  modules  will  be  enclosed  in  sealed  metal  cases  to  provide 
complete  mechanical  and  EMI/EMP  protection.  These  rugged,  sealed  modules  will  permit  flight-line  replace¬ 
ment.  All  modules  will  be  cooled  by  conduction  to  cold  plates  in  the  integrated  racks.  Either  forced  air 
or  liquid  cooled  versions  of  the  rack  could  be  used. 


THE  FUNCTIONAL  ARCHITECTURE 

Future  aircraft  will  need  to  have  a  functional  rather  than  a  subsystem  oriented  architecture.  Emphasis 
in  system  operation  and  design  will  be  on  the  functions  which  must  be  performed  to  achieve  the  mission. 

The  physical  pieces  of  sensor/effector  hardware  required  to  accomplish  the  functions  will  no  longer  drive 
system  design  and  implementation  considerations.  System  functions  will  frequently  be  accomplished  with  in¬ 
put  or  participation  from  what  are  now  typically  stand  alone  subsystems.  Sensing  and  computation  will  be 
performed  where  it  provides  the  most  benefit,  rather  than  where  it  has  been  traditionally  performed.  As  a 
result,  in  the  accomplishment  of  functions,  sensors  will  augment  each  other.  Detection  of  targets  for 
example,  can  be  performed  by  a  combination  of  radar  input,  EW  input,  FLIR  input,  laser  input  and  pilot  input 
to  a  common  functional  algorithm.  Individual  sources  of  data  will  be  weighed  most  heavily  when  the  con¬ 
ditions  for  operation  of  that  subsystem  are  best.  Failure  of  a  sensor  will  not  change  the  operation  of  the 
function,  but  will  merely  modify  the  accuracy,  certainty,  range,  etc.,  with  which  targets  can  be  detected 
to  the  extent  that  the  failed  sensor  would  have  provided  data.  Pilot  workload  will  be  dramatically  reduced 
because  formerly  separate  data  will  be  already  integrated  and  appropriately  weighed  according  to  its  value. 
Fusion  of  the  data  in  this  manner  will  allow  the  pilot  more  time  to  focus  upon  the  intent  of  his  mission  end 
the  expression  of  that  intent  to  the  avionic  system  to  allow  it  to  properly  weigh  decision  inputs.  A 
functional  rather  than  subsystem  orientation  will  also  provide  benefits  in  the  area  of  system  availability. 
When  coupled  with  the  standard  modules  of  the  physical  architecture,  failed  devices  will  be  able  to  be  re¬ 
placed  on-line  with  spare  modules  to  maintain  the  operation  of  critical  functions.  Functional  orientation 
will  promote  common  algorithmic  approaches  which  can  be  supported  by  common  hardware  modules.  In  addition, 
it  will  decrease  the  tendency  to  build-in  geographical  proximity  ss  a  subsystem  design  requirement.  Fail¬ 
ure  of  one  of  these  modules  will  be  circumvented  by  the  reloading  of  a  similar  module  in  another  part  of 
the  system  with  the  appropriate  software  to  continue  operation.  This  reallocation  of  processing  to  ac¬ 
complish  functions  can  range  from  simple  computational  modules  to  complex  common  signal  processing  elements. 
Safety  of  flight  critical  systems  will  also  be  benefited  by  a  functional  approach  to  system  design.  Im¬ 
proved  system  error  checking  capability  can  be  achieved  through  the  analytical  comparison  of  other  aircraft 
sensor  data  without  the  necessity  for  unneeded  duplication  of  flight  critical  sensor  systems.  Reliance 
will  be  upon  total  system  capability. 

THE  INFORMATION  TRANSFER  ARCHITECTURE 

fc  -«i  ty>*  cl  uDdfelair  mtfMbwrwa  will  be  tatvc;  It  dtliee  utwd  taT.'it  .1  iU  -yp.  'iwm  w 
to  accomplish  the  proposed  functional  architecture.  Multiplex  communication  will  be  used  between  modules, 
rsther  thsn  just  between  LRUs  ss  in  existing  designs.  This  approach  will  largely  eliminate  many  thousands 
of  mechanical  electrical  connections  thst  are  used  in  current  avionic  equipment.  It  is  ironic  that,  while 
these  connectors  in  current  systems  facilitate  rapid  field  replacement  of  defective  elements,  they  slso 
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contribute  failures  that  increase  the  number  of  maintenance  actions.  In  modern  digital  equipment,  even  a 
momentary  break  in  a  connection  tends  to  register  as  a  hard  failure.  Evidence  indicates  that  connection 
related  problems  may  be  responsible  for  a  large  segment  of  the  could-not-duplicate  (CND)  and  re-test-OK 
(RTOK)  problems  that  tax  maintenance  resources  and  that  tend  to  repeat  in  flight  and  thereby  reduce  combat 
effectiveness . 

Figure  5  is  a  block  diagram  showing  an  example  and  benefits  of  such  an  architecture.  This  example  is 
an  inertial  navigator  that  uses  digital  multiplex  to  the  module  level  and  is  built  almost  totally  from 

standard  modules.  Elements  such  as  those  shown  in 
Figure  5  become  building  blocks  in  a  conventional 
sense  for  larger  subsystems  and  systems  in  much  the 
same  way  that  the  standard  modules  are  building 
blocks  for  this  element.  The  same  standard,  digital 
a.,  jjdiw  •  •  M  •  ^  t,'_J 

levels  to  simplify  design  and  permit  necessary  data 
interchange  at  all  levels  of  the  system. 

The  two  most  essential  features  of  the  informa¬ 
tion  transfer  architecture  are  the  previously  des¬ 
cribed  'multiplex  to  the  module'  feature  and  the 
reliance  upon  a  switched  communication  network  rather 
than  a  bus  structure  for  that  information  transfer. 
Dynamically  switched  point-to-point  communications  is 
provided  between  devices  in  the  avionic  system  allow¬ 
ing  any  device  to  communicate  with  any  other  device. 

This  switched  approach  permits  many  simultaneous 
communications  to  occur,  provides  alternate  communi¬ 
cation  paths  for  reliability  and  reconfiguration,  and 
FIGURE  5.  ALL-MULTIPLEXED  ARCHITECTURE  FOR  AN  provides  isolation  of  failures  in  communications  to  a 

INERTIAL  NAVIGATOR  USING  STANDARD  MODULES  single  computational  module.  All  of  this  is  accomplished 

with  a  highly  regular  network  requiring  only  one  multi¬ 
plex  terminal  per  computer.  Failure  isolation  is  particularly  important  to  flight  critical  functions  which 
need  to  interact  with  the  remainder  of  the  avionic  system  but  which  must  be  protected  from  failure  in  non¬ 
flight-critical  and  non-redundant  subsystems.  The  switched  network  information  transfer  architecture  is 
also  fully  extendable  to  provide  for  the  transfer  of  non-digital  information  such  as  video,  electrical  power 
and  RF  energy.  In  a  fully  functional  architecture  the  distribution  of  these  types  of  information  must  be 
fully  coordinfted  with  the  exchange  of  digital  information.  The  common  control  mechanism  for  data  exchange 
provided  by  the  switched  network  approach  achieves  this  coordination  capability,  provides  regularity  in 
system  design,  and  can  dramatically  reduce  the  wiring  and  control  complexity  of  the  aircraft  while  sub¬ 
stantially  improving  operational  effectiveness. 

Advanced  multiplex  networks  of  the  type  needed  for  such  applications  have  already  been  designed  and 
breadboarded  for  digital  and  video  information  exchange.  The  networks  employ  the  advanced,  fault  isolating, 
switching  techniques  to  provide  the  necessary  data  transfer  rates  to  handle  both  high-speed  digital  and 
wide-band  video  type  data.  The  terminals  transmit  less  than  one-quarter  watt  of  power  and  can  be  con¬ 
structed  entirely  with  VLSI  chip  technology. 

THE  CONTROL  SYSTEM  ARCHITECTURE 

The  complex  avionic  systems  of  the  future  will  require  improved  control  mechanisms  to  ensure  reliable 
and  effective  operation.  The  switched  network  information  transfer  architecture  supports  distributed  con¬ 
trol  and  provides  the  freedom  to  implement  any  desired  combination  of  central  control  and  local  autonomy. 

Some  degree  of  local  autonomy  will  certainly  be  required  for  efficient  system  operation  as  the  number  of 
simultaneous  functions  to  be  accomplished  increases.  Accordingly,  the  control  in  future  avionic  systems 
will  be  accomplished  at  several  levels.  At  the  top  level  will  be  the  expression  of  the  intent  of  the 
mission  (and  of  the  pilot).  Of  necessity,  all  actions  of  the  total  system  must  be  consistent  with  these 
mission  objectives.  Implementation  at  this  level  will  be  accomplished  by  the  pilot  and  a  system  level 
artificial  intelligence  capability. 

The  next  level  will  be  the  control  of  individual  functions,  each  of  which  may  involve  several  sensors/ 
effectors.  As  long  as  the  actions  taken  at  this  level  are  consistent  with  the  top  level  intent  of  the 
mission/pilot,  autonomy  of  operation  will  be  allowed.  A  change  in  pilot  intent  would,  of  course,  be  re¬ 
flected  into  appropriate  and  coordinated  pctential  changes  in  individual  function  executions.  Allowing 
autonomy  at  this  level  simplifies  the  implementation  (and  also  the  test)  of  the  system.  It  further  allows 
much  faster  reactions  to  changes  in  the  environment  since  the  decisions  can  be  made  region  by  region  rather 
than  centrally.  Artificial  intelligence  may  also  be  needed  at  this  level  to  determine  the  best  weighing 
of  information  and  to  determine  the  best  course  of  action,  within  the  constraints  of  the  higher  level 
objective . 

Additio  il  lower  levels  of  control  may  similarly  be  required,  each  operating  within  the  constraints 
imposed  by  the  intent  and  goals  of  the  next  higher  level.  Operation  of  the  avionic  system  in  a  sense 
parallels  that  of  a  well  honed  military  ccamand  structure  which  allows  subordinates  freedom  of  action  with¬ 
in  the  constraints  of  the  objectives  provided  by  their  superior  officers. 

A  common  family  of  executive  software  and  executive  control  structures  will  be  used  to  support  all  of 
these  levels  of  operation.  Commonality  in  software  modules  will  be  similar  to  the  conroonality  in  hardware 
modules  discussed  in  the  section  on  physical  architecture.  A  family  of  executive  and  control  structure 
modules  can  b*  well  tested  with  the  needs  of  any  individual  decision  level  being  accomplished  reliably  by 
an  appropriate  set  of  software  modules. 

Tt*  <  4/  *  -  h  m  (ifliBULui  «Tt~sAt  »yste«  ttl,  Irtavil)  a pvt,  extensive 

on-board  self  test  of  software  and  hardware  to  ensure  reliable  operation  and  to  support  on  line  reconfiguration 
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to  improve  aircraft  availability.  The  standard  hardware  modules  with  multiplex  interface  between  modules 
are  particularly  well  adapted  to  complete,  on-line  self-test.  First,  the  many  thousands  of  interconnects 
which  exist  in  conventional  avionics  are  eliminated,  which  directly  reduces  the  scope  of  module  self-test. 
Simplified  interface  equates  to  simplified,  more  comprehensive  self-test.  Second,  multiplex  lends  itself 
to  end-to-end  testing  with  a  pulse-by-puls i  self  test  for  100%  confidence.  Third,  large  scale  and  high 
density  integrated  circuit  technology  makes  it  possible  to  provide  special  self-test  chips  that  can  be 
utilized  in  each  standard  module. 

Vesting  i *  rtnfcl  datttig  ( 1  i-gl t  ,  fat1  ^.t  ***  ant  ••  '  •.*«<'  *  '  V 

environment  in  which  they  occur.  Most  CNDs  and  RTOKs  are  eliminated.  In  addition,  the  built-in  test 
capability  of  the  modules  and  the  advanced  multiplexed  communications  make  it  practical  to  provide  on-line, 
hot  spares  for  many  critical  functions.  Such  spares  not  only  permit  systems  to  heal  themselves  after 
failures,  but  may  also  allow  maintenance  deferral.  If  a  system  has  corrected  a  failure,  the  urgency  to  re¬ 
place  failed  modules  between  missions  is  reduced.  Finally,  the  test  capabilities  provide  the  maintenance 
personnel  with  fully  automatic  identification  and  location  of  failures,  thereby  enabling  rapid  line  replace¬ 
ment  of  failed  modules. 

CONCLUSIONS 

inappropriate  architectural  approaches  in  the  physical,  tunctional,  information  transfer,  and  controx 
system  areas  are  the  key  to  future  avionic  capabilities.  The  appropriate  architectures  will  provide  drama¬ 
tic  improvements  in  system  performance  while  simultaneously  improving  system  availability,  supportability , 
and  at 1  WaiAlA-f}  .  Tnt  *  /itWittfc  *  d  fAttfkat  tetAmtiogy  to  atfdreve  rots'  artirfct  Ittm.i  bnptore  ■ 

ments  are  already  here  and  simply  need  to  be  improved,  properly  applied,  and  integrated.  The  resulting 
weapon  systems  will,  however,  have  widespread  effects  in  many  areas  of  operations,  logistics,  and  equipment 
acquisition.  Chant es  will  be  required  in  the  war  pilots  are  trained  and  conduct  their  missions.  The 
proper  pilot/vehicle  interface  will  need  to  be  developed  to  fully  allow  the  pilot  to  act  as  a  system  manager. 
At  the  same  time  data  must  be  provided  to  assure  pilot  confidence  that  the  automated  system  is  accomplish¬ 
ing  properly  the  detailed  operational  tasks  which  were  formerly  accomplished  manually. 

'  4  Bud  *441  iooasr*- 

alignments  will  change.  Government  procurement  policies  will  be  al teredS^Common  modules  will  likely  be 
procured  directly  by  the  military  from  software  and  hardware  module  sources  and  will  be  provided  to  avionic 
vendors.  Avionic  systems  developers  will  find  themselves  creating  special  sensor  and  effector  modules  and 
function-unique  software  to  be  used  with  modules  common  to  many  other  uses.-  Because  most  functions  of  the 
Avionic  Intermediate  Shop  will  disappear,  the  large  organizations  now  associated  with  this  function  will  be 
greatly  reduced.  "iJith  large  numbers  of  throwaway  modules,  depot  repair  facilities  and  organizations 
wil'  «&TTak,  r  rh»  iimrM.r  will  rx-m,rr  r  rt  1  *wuuitt<-rnri  r 

These  changes  can  provide  far  more  Air  Force  fighting  power  per  dollar.  The  task  1b  technically 
achievable.  The  challenge  is  to  break  free  of  the  comfortable  post-World  War  II  path  of  avionic  design 
and  support.  Instead  of  incremental  applications  of  advanced  technologies  with  incrementally  small  improve¬ 
ments,  a  revolutionary  and  concerted  technology  application  to  gain  a  decisive  advantage  should  be  made. 

The  future  of  Air  Force  effectiveness  is  in  the  balance. 

ACKNOWLEDGEMENT 

The  author  wishes  to  acknowledge  the  earlier  p  stem  architectural  *  *•  '  I  i f  VAl  * 

the  direct  contributions  to  this  article  by  Mr.  Larry  Klos,  both  of  whom  are  outstanding  engineers  at  the 
Fort  Worth  Division  of  General  Dynamics. 


DISCUSSION 


F.Broecker,  Ge 

Does  an  improved  Avionics  Architecture,  which  you  advocate,  bring  any  relief  as  to  the  development  and 
substantiation  of  the  functional  requirements/specifications  before  it  is  transformed  into  computer  language  and 
algorithms? 

Author's  Reply 

Partially,  the  new  architecture  will  not  help  to  decide  what  functions  are  needed  or  how  they  are  specified.  It  can, 
however,  make  early  evaluation  of  the  validity  of  those  functional  requirements  easier  since  the  hardware, 
architecture,  language,  and  interfaces  are  known  beforehand.  The  functional  uniqueness  resides  in  the  algorithms 
and  software.  Thus,  the  unknowns  are  considerably  reduced  in  development  and  substantiation. 


F.Broecker,  Ge 

In  case  the  extent  and  importance  of  the  functional  requirements/specs  are  unchanged  with  the  current  extent,  is 
there  any  other  siinplification/relief  that  justifies  the  statement  that  the  software  is  simpler  and  cheaper  with  the 
new  architecture? 

Author’s  Reply 

The  software  is  simpler  and  cheaper  because  most  of  the  system  will  be  combinations  of  a  few  common  modules  and 
library  software,  with  only  the  function-unique  software  to  be  implemented  and  tested.  This  regularity  is  also 
amenable  to  automated  software  procedures.  In  addition,  designing  software  functionally,  to  operate  by  expression 
of  intent,  decreases  module  connectivity  making  individual  software  modules  easier  to  write  and  test. 


M.Burfcrd,  UK 

While  it  is  true  that  more  and  more  relatively  inexpensive  and  powerful  hardware  is  allowing  the  development  of 
computers  with  '‘reasoning”  capabilities,  is  it  not  true  these  developments  are  more  likely  to  cause  a  shift  in  the 
emphasis  of  the  software  role  as  opposed  to  a  revolution?  As  the  software  firms  up  into  hardware,  the  task  r  f  the 
software  component  will  be  relieved  of  the  more  mundane  activities.  This  will  surely  not  have  the  net  effect  of 
reducing  the  software  components  role,  but  will  allow  it  to  concentrate  on  the  more  difficult  to  implement 
executive  type  of  decisions,  such  as  exception  handlers  and  data  presentation  editor. 

Author's  "<tply 

The  software  role  is  indeed  more  evolutionary  as  opposed  to  revolutionary  versus  the  revolutionary  increase  in 
hardware  capability  and  architecture.  Some  “revolution"  is  needed  in  software,  however,  in  the  way  applications 
are  partitioned.  “Intent  driven"  operation,  for  example,  is  a  significant  departure  from  current  practice.  Other 
software  revolutions  will  come  in  computer  automated  software  development,  documentation  and  maintenance. 

We  don’t  see  that  the  "software  firms  up  into  the  hardware"  (firmware)  to  any  greater  extent  than  now,  but  that 
trie  hardware  will t  “numSpecific"  ofttif  taaded tixnrini&i  <UrcT  -wdc,  firmware;.  I  orrotiTinc  TuiictiotiS.  Common 
modules  and  library  software  will  constitute  a  large  part  of  the  system.  This  will  not  have  the  "net  effect  of 
reducing  the  software  components"  but  of  increasing  it,  but  in  a  positive  sense  overall.  The  hardware 'software 
rebalance  will  more  likely  come  in  automated  procedures  and  a  reduction  in  the  percentage  of  time  devoted  to 
soft  vare  maintenance. 


W.McKinlay,  UK 

It  is  agreed  that  systems  have  evolved  so  far  but  perhaps  the  revolution  required  is  a  proper  unacceptable  constraint 
to  use  a  bus  connecting  function  module  because  of  the  major  changes  in  function  permitted  by  later  technology 
and  the  technology  dependence  on  sensor  characteristics.  How  can  standardization  be  made  to  pay  off  without 
making  some  of  the  desired  system  features  impossible  to  achieve  or  without,  in  practice,  making  subsystems  more 
extensive  or  difficult  to  develop  to  the  desired  performance? 

Author's  Reply 

1  hi  gull  id  fitfi  JTCfifttCtOIC  uhil  it  flIIt'riaiA  a1.". J  •  Ju,e5  it  t-j  anticipate  lirtuTT  T£quilClllCllts  in  SuiTi  fuiiJjifienTat 

parameters  as  data  flows,  bandwidth,  operations  per  second,  etc.,  then  to  implement  in  the  modules  what  current 
technology  will  support.  As  the  technology  changes,  the  new  technology  will  change  only  the  number  of  modules 
required  per  function,  and  the  system  will  be  transparent  to  that  change.  The  bus  interface  at  the  functional  cluster 
level  is  not  a  factor  in  taking  advantage  of  technology  (major  technology  advances  have  been  made  in  the  F-16 
system  without  abandoning  the  basic  MIL-STD-1553  interface).  While  it  is  true  that  the  performance,  especially  in 
the  sensor  area,  is  tecnnology  dependent,  a  properly  designed  architecture  should  be  transparent  to  those  changes.  A 
Standard  that  does  not  have  this  technology  transparency  is  vulnerable  to  being  superseded  in  any  event. 
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SUMMARY 


'-'The  complexity  of  tactical  weapon  delivery  has  been  greatly  Increased  by  the  advent  of  new  weapons, 
the  enormity  of  enemy  air  defenses  and  the  awesome  capability  of  new  digital  technology.  However, 
careful  ssseasment  of  the  tactical  requirements  becomes  even  more  Important  If  a  truly  effective 
marriage  of  airframe,  avlonlca  and  weapons  Is  to  be  achieved.  A  review  of  a  typical  tactical  mission 
requirements  battlefield  Interdiction^  establishes  a  base  for  derivation  of  functional  requirements  on 
which  an  Integrated  attack  system  architecture  can  be  designed.  The  result  Is  a  need  for  a 
multi-sensor,  multi-mode  capability  functionally  integrated  to  achieve  the  flexibility  required  by  the 
mission. 

X 


1.0  INTRODUCTION 

When  the  British  Royal  Plying  Corps  In  World  War  I  conceived  the  Idea  of  a  fighter-bomber  by 
Installing  four  23  lb  bombs  on  s  Sopwlth,  few  foresaw  the  complexity  of  today’s  weapon/aircraft 
Interface  and  the  target  environment  In  which  the  fighter  bomber  must  operate.  Prom  this  modest 
beginning  Into  the  1930s,  tactical  weapons  still  consisted  principally  of  guns  and  high  explosive  bombs, 
and  antl-alr  defenses  relied  on  guns  of  various  caliber.*  The  advent  of  the  tactical  missile,  air  to 
air,  air  to  surface  and  surface  to  air,  brought  about  dramatic  changes  In  both  fighter  bomber  weapon 
control  requirements  and  In  the  flexibility  and  lethality  of  air  defenses.  Through  this  period  of 
change,  tactical  fighters  have  undergone  an  infusion  of  technology  that  leaves  their  flight  performance 
and  weapon  control  capability  unparalleled.  The  question  arises,  however,  do  these  awesome  capabilities 
Indeed  permit  today’s  fighter  pilot  to  successfully  destroy  a  determined  enemy?  Are  the  aircraft 
characteristics,  weapon  control  system  capabilities  and  the  weapons  truly  compatible?  Are  the  tactical 
requirements  fully  reflected  In  the  total  engagement  system  design?  There  Is  no  clear  cut  "yes"  or  "no" 
answer  to  these  questions.  However,  It  behooves  the  systems  designers  to  critically  examine  where  we 
are  and  where  our  future  systems  must  go.  Airframe  designers  may  lean  In  one  direction,  weapons  control 
system  designers  In  snother  and  weapons  designers  yet  a  third  direction.  Yet  on  one  point  all  will 
probably  agree  —  the  next  generation  must  be  an  Integrated  attack  system  featuring  multi-sensors  and  a 
wide  range  of  modes  to  meet  the  difficult  tactical  weapon  delivery  requirements. 

However,  this  Integrated  attack  system  must  be  a  departure  from  the  popular  conception  of 
"Integration".  No  longer  can  a  system  architect  assemble  a  group  of  "elements"  with  given  performance 
characteristics  and  "Integrate"  them  through  some  common  processor  and  achieve  the  maximum  capability  of 
the  system.  Today's  requirements  dictate  that  each  "element"  (In  the  case  of  weapon  control  usually 
sensors)  must  be  designed  with  full  knowledge  of  Its  role  In  the  Integrated  system.  Software  must 
reflect  an  understanding  of  the  multi-mode,  multi-role  functions  required  to  achieve  detection, 
acquisition,  tracking  and  delivery  compatible  with  a  wide  range  of  weapons.  Shared  processing  and 
shared  apertures  will  be  common.  Stealthy  operation  Imposes  stringent  demands  on  control  of  own 
emmlsslo  .  and  judicious  use  of  the  enemy's  emmlsslons.  But  as  a  bottom  line,  the  capabilities 
Incorporated  In  the  system  must  not  be  allowed  to  proliferate  to  the  extent  technology  will  bear  but 
must  be  carefully  matched  to  the  tactical  requirement  to  be  fulfilled. 

This  paper  looks  at  a  pressing  tactical  requirement  —  destruction  of  enemy  armored  forces  In  the 
second  echelon.  It  examines  the  functional  requirements  derived  from  these  operational  considerations 
and  matches  them  with  the  elements  of  weapon  control  needed  to  perform  the  functions.  Finally,  the 
techniques  of  Integration  and  the  Impact  of  technology  are  discussed. 


2.0  TACTICAL  REQUIREMENTS 

As  an  Illustrative  example  of  the  Impact  of  tactical  requirements  on  weapon  system  design,  the 
battlefield  Interdiction  mission  or  destruction  of  enemy  armored  forces  In  the  second  echelon,  has  been 
chosen.^  The  most  Important  aspects  from  a  system  design  standpoint  are  the  characteristics  of  the 
targets,  constraints  In  acquiring  the  target,  how  to  get  to  and  depart  from  the  target  area,  the  weapons 
Involved  and,  the  most  elusive  of  all,  the  tactics  required  to  get  the  weapon  on  the  target-*, which  Is 
often  Integral  with  getting  to  and  departing  from  the  target  area. 

2.1  Target  Characteristics 

It  Is  not  sufficient  to  just  characterise  the  target  In  terms  of  its  radar  cross-section,  IR 
emmlsslons  or  minimum  expected  velocity.4  To  derive  functional  requirements  for  the  integrated  attack 
system  the  physical  characteristics,  the  vulnerable  aspects,  the  modes  of  operation  and  deployment  are 
all  Important  Inputs.  In  this  example,  the  targets  are  not  only  tanks  but  self  propelled  artillery, 
armored  personnel  carriers,  trucks  and  mobile  air  defenses.'  The  fact  that  they  are  metal,  are 
physically  large,  radiate  heat  when  running,  are  camouflaged,  all  are  Important  In  choice  of  sensors. 
Since  the  purpose  of  the  second  echelon  la  to  exploit  first  echelon  breakthrough,  the  likelihood  that 
the  targets  will  be  on  the  move,  on  the  roads  and,  for  tactical  control,  in  proximity  to  one  another  Is 
high.  RF  emissions  from  the  gun/mlssle  defense  radars  and  from  communications  Is  a  likelihood. 


2.2  Expected  Constraints 

The  highly  sophisticated  and  effective  enemy  air  defense  environment  is  the  principal  constraint  on 
integrated  attack  syatem  design. ^  The  attacking  aircraft  must  fly  very  low  and  very  fast  to 
survive.*'  This  brings  to  bear  other  complications  for  target  acquisition.  Terrain  masking  now 
becomes  extremely  important.  Armored  forces  proceeding  down  the  center  of  a  200  meter  roadway  with  10 
meter  high  trees  on  either  aide  presents  a  six  degree  mask  to  an  attacking  aircraft-  If  the  aircraft  is 
at  70  meters  altitude,  the  target  will  not  be  within  the  pilots  line-of-sight  until  he  is  only  about  670 
meters  away  or,  at  244  metera/sec  airspeed,  about  2.75  secs  from  the  target.  An  alternative  to  increase 
the  line-of-aight  range  ia  to  popr-up  to  a  higher  altitude  with  the  attendant  risk  of  greater  exposure  to 
enemy  defensea.  Also  the  terrain  presents  problems  for  ingress  and  egress  to  the  target.  The  speed  and 
altitude  dictated  by  the  miasion  impact  the  terrain  follow/ terrain  avoidance  requirements. 

Night  and  weather  conditions  are  also  constraints  since  this  miasion  requires  the  system  to  contend 
with  both.  Choice  of  frequency  for  the  sensora  ia  impacted  by  the  severity  of  the  weather  requirement 
at  low  altitude.  Background  clutter  Is  also  a  constraint.  The  multi-sensor  mix  and  particularly  the 
multi-mode  requirement  on  each  aensor  is  impacted.  Signal  procesalng  requirements  are  alao  vulnerable 
to  the  kinds  of  backgrounds  expected.  Overlaid  is  the  significant  progress  made  by  the  enemy  in 
Electronic  Counter  Measurea  (ECH)  and  Electronic  Counter-Counter  Measures  (ECCM)  which  will  make  his 
defenses  even  more  difficult  to  penetrate. ^ 


2.3  Weapon  Selection 

In  the  end,  the  weapon  ultimately  dictates  the  syatem  design.  For  destruction  of  enemy  armor, 
the  moat  effective  weapons  currently  in  the  free  world  inventories  are  cluster  munitions,8 
line-of-sight  missiles  ®  and  guns.  Cluster  munitions  are  delivered  as  area  weapons  and,  If  delivered 
from  low  altitude,  usually  require  overflight  of  the  target  area.  Most  current  line-of-sight  missiles 
are  uou  taunct,  and  leave,  VLc.eioie  tequfre  what  Coe  cafget  be  illumlnst-eo  until  Che  missile  luipaeLa. 
Guns,  of  course,  require  closing  to  a  short  range  for  maximum  effectiveness.  All  of  these  weapons, 
therefore,  require  that  the  target  be  within  the  pilots  (or  sensors)  line  of  sight  at  launch.-*^ 
Weapons  projected  for  production  will  have  launch  and  leave  capabilities,^  and  may  be  launched  both 
ofiSei  iu  the  Laigct  Sud  WnlluUt  line  ol  slgot.  at  uuk  ol  iaun.fl.  These  cliSldwCfel  ls"i  ice  will  ubvTbJsly 
impact  heavily  on  the  syatem  requirements.  Where  currently  minimum  launch  range,  line-of-sight  needs, 
and  illumination  requirements  dictate  acquisition  ranges  and  targeting  accuracies  and  resolutions. 
Removal  of  theae  constraints  will  bring  new  sensor  modes  into  vogue  and  change  requirements  drastically. 


a.. a  Target  Area  ingress/ Egress 

Of  even  greater  Impact  on  functional  requirements  is  the  problem  of  getting  to  the  target  area  and 
returning.  It  is  obvious  that  in  face  of  the  expected  enemy  defenses  that  ingress  and  egres3  would  be 
expected  to  be  at  low  altitude  with  high  speed.  ^  In  addition,  this  capability  would  be  required  at 
night  and  In  all  weather.  Impacting  on  the  design  is  the  expected  terrain  including  wire  and  tower 
avoidance.  The  navigation  accuracies  to  reach  cued  target  coordinates  are  quite  high  requiring  accurate 
Inertial  Navigation  System  (INS)  update.  The  expected  mission  times,  while  not  as  long  as  deep 
interdiction  missions,  are  still  significant  in  terms  of  expected  INS  errors.  Also  of  considerable 
tapfctl  Is  f*  fSqmtfSSw  I  lev  a  - 1 1 Is  mo?*  ItCLj  mgT&iM  fir  '  4  fc  't  «  f  1 

air-to-air  search  along  with  terrain  follow  and  navigation  update  are  considerable  loads  for  a  radar. 
The  interleaving  of  modes  within  a  sensor  or  among  sensora  Is  a  critical  issue  dictated  by  the  users 
requirements. 


2.5  Other  Mission  Impacts 

Choosing  the  battlefield  interdiction  mission  as  an  example  of  how  tactical  requirements  should 
Influence  weapon  system  design  does  not  ignore  the  Impact  of  multi-mission  requirements  on  tactical 
aircraft.  Obviously  all  mission  requirements  must  be  assessed  in  the  same  manner  with  Inevitable 
compromiaes  In  design.  The  thrust  in  this  paper,  however,  is  to  insist  that  compromise  in  design  be 
determined  by  total  requirements  assessment. 


3.0  DERIVATION  OF  FUNCTIONAL  REQUIREMENTS 

The  functional  requirements  for  the  avionics  of  the  tactical  aircraft  are  driven  by  the  missions  to 
be  performed  by  the  weapon  aystem.  Since  most  current  tactical  aircraft  and  likely  most  future  aircraft 
will  be  required  to  perform  an  even  wider  variety  of  missions,  the  functional  requirements  are  expansive 
while  demanding  precision  in  many  segments  of  the  mission. 

3.1  Mission  Timelines 

A  typical  tactical  air-torground  mission  profile  as  shown  schematically  in  figure  2-1  Imposes 
requirements  vastly  different  for  each  segment  of  the  mission  with  the  greatest  avionics  load  usually 
occurring  at  or  near  weapon  delivery.  A  wide  variety  of  such  timelines  exist  for  the  typical  tactical 
aircraft. 

The  avionics  system  related  functions  associated  with  each  miasion  segment  for  the  ground  target 
attack  mission  are  shown  In  table  2-1.  Fur  mission  success  the  avionics  systems  must  be  capable  of 
providing  timely  data  with  the  accuracy  oemanded  by  each  mission  segment.  The  type  of  terrain,  the 
enemy  defensive  posture  and  the  compliment  of  weapons  to  be  delivered  influence  the  performance  level 
required  of  avionics  systema. 

Various  levels  of  activity  will  exist  within  each  mission  segment  as  well  as  between  mission 
segments.  Crises  may  precipitate  high  activity  levels  during  mission  segments  which  normally  are  quiet, 
especially  If  multiple  anomalies  or  failures  occur  simultaneously.  It  is  during  the  peak  activity 
periods  that  the  real  stress  of  the  man  and  the  machine  becomes  apparent.  Thus  the  avionics  as  well  as 
the  airframe  and  weapons  muat  be  organised  to  maintain  stability  during  periods  of  intensive  pilot 
attention  to  a  distracting  occurrence  which  may  temporarily  consume  his  activity.  Mission  success  may 
frequently  hinge  upon  being  able  to  cope  with  crises  since  the  enemy  will  try  to  make  life  difficult  for 
the  attacker. 


Table  2-1  PRIORITY  OF  FUNCTIONS  TO  BE  ACCOMPLISHED  DURING  GROUND  TARGET 
ATTACK  MISSION  SEGMENTS 


Function/Mission  Segment 

Taxi 

Climbout 

Dash 

Cruise, 

Loiter 

Descent 
at  FEBA 

Penetra¬ 

tion 

Search  & 
Acquisi¬ 
tion 

Attack  & 
Guidance 

Exit 

System  Missionization 

2 

System  Checkout  &  Test 

3 

2 

Inflight  Performance  Monitoring 

4 

2 

2 

2 

2 

2 

Communications 

1 

3 

3 

5 

5 

8 

8 

8 

Navigation 

1 

1 

3 

3 

3 

3 

3 

Terrain  Follow  &  Avoidance 

1 

1 

1 

1 

1 

Airborne  Target  Search  &  10 

4 

2 

4 

6 

7 

7 

5 

Threat  Detections 

4 

5 

5 

4 

Ground  Target  Detection  &  Track 

4 

Weapon  Delivery 

4 

Detection  of  Targets  of  Opportunity 

7 

6 

6 

7 

I3-02M-IA-2 


FEBA 


l  (M22S-BA1 


Figure  2-1 j  AIR-TO-GROUND  TARGET  ATTACK  MISSION  PROFILE 
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The  mission  timeline  requires  careful  system  design  and  mission  planning  since  it  will  continue  to 
unfold  endlessly  as  the  mission  progress,  never  pausing  to  let  the  system  or  pilot  catch  up.  The 
mission  segments  must  allow  for  periods  of  adjustment  ar.d  must  compensate  where  possible  for  temporary 
sensor  or  pilot  lags  which  may  occur  becauae  of  this  continuing  evolution  of  the  mission  timeline. 
Planning  relaxed  timelines  at  the  peak  load  period  becomes  difficult  of  course  because  the  peak  load 
period  place  severe  demands  upon  the  system. 

3.2  Accuracy/Resolution  Computation 

The  system  accuracy  requirements  change  depending  upon  the  system  function  being  provided.  The 
ability  to  adjust  the  system  to  the  requirements  of  the  current  function  is  desirable  to  optimize  the 
utilization  of  sensor  and  computational  assets.  This,  however,  may  be  unachievable  because  of  hardware 
Inflexibility.  Some  computations  may  be  characterized  by  inaccuracies  due  to  long  periods  between  data 
points,  others  by  frequent  data  points  which  Individually  have  sizable  measurement  errors. 

A  primary  function  of  the  aircraft  avionics  in  all  missions  is  that  of  navigation.  The  navigation 
requirements  range  from  several  kilometers  when  flying  over  water  because  of  the  long  intervals  between 
updates  without  external  positional  data,  to  a  few  meters  where  frequently  updated  positional  data  is 
provided  by  highly  accurate  weapon  delivery  sensors.  In  genersl  the  navigation  error  corrections  should 
be  made  quickly  as  long  as  the  uncertainty  does  not  place  '.he  update  point  out  of  range.  With  maps 
created  by  on-board  radar  or  IR  sensors  or  external  navigation  aids  such  as  satellites,  navigation 
system  update  should  provide  location  determination  to  the  accuracy  required  for  flying  a  predetermined 
course. 

For  Interdiction  and  target  acquisition  the  navigation  requirements  are  much  more  severe  for  low 
altitude  operations  than  for  flying  from  point  to  point  at  high  altitude.  Blind  delivery  of  weapons 
srtleh  Jj  ml  flame  ihals  OW  i ' ru-iliml  iMleiWe  lire  1* tequUi-a  Xltl  now* 

The  most  difficult  task  for  the  avionics  system  in  the  segment  immediately  preceeding  weapon 
delivery  is  detection  of  the  target  and  focusing  the  weapons  system's  attention  on  the  target  for  the 
attack.  In  the  air-to-air  engagement  this  target  cueing  event  is  usually  characterized  by  achieving  a 

jf  lalgtH  signal  rlw-w  t  ?  _  .Hgfva.  0  .vfci  pt*  Jit  Otlorfct+oii  tu  l\e 

engagement  the  event  is  characterized  by  the  target  becoming  discernible  from  the  background  clutter  or 
the  elimination  of  terrain  masking  of  the  target.  In  either  the  air-to-air  or  air-to-ground  case  the 
time  available  for  weapon  release  tactics  and  delivery  has  a  practical  limit  imposed  by  the  point  in  the 
mission  where  target  detection  ind  cueing  occurs. 

-ine  accuracy  or  target  cueing  win  determine  w.ietner  tne  ngnt  target  is  attacxeu  ana  tne  proper 
decisions  concerning  the  attack  are  made.  The  accuracy  is  twofold.  It  is  concerned  with  the  exact 
angle  and  range  of  the  target  and  the  correctness  of  the  detections  being  truly  a  target.  These 
accuracy  requirements  grow  more  critical  as  the  urgency  of  decision  grows. 

in  accuracy  a "  Ttb  i  u  1 1 .  :w  rcq .. l rvucrntly  I  f  d*  avtoi  irts  . ut d  I n  wtjrpo.*  i  Xt  -tTh: 

type  of  weapon  being  delivered.  A  weapon  with  a  terminal  seeker  for  instance,  has  a  reduced  requirement 
for  delivery  precision  over  an  unguided  weapon  since  the  terminally  guided  weapon  will  remove  the  weapon 
delivery  system  launch  errors  within  the  limits  of  the  weapon's  guidance  system.  This  requires  the 
weapon  delivery  system  to  be  matched  to  the  weapons  used  for  the  particular  mission.  It  must  be 
compatible  with  the  targeting  requirements  of  each  weapon  carried  on  each  mission.  In  past  systems  this 
accuracy  requirement  has  been  built  around  the  most  severe  targeting  requirement.  Future  systems,  with 
their  software  flexibility,  may  provide  a  degree  of  adaptlblllty  which  allows  the  targeting  accuracy  to 
be  matched  to  the  accuracy  requirement  of  the  weapon  to  permit  the  avionics  sensors  and  processors  to 
better  service  the  other  tasks  being  performed  simultaneously.  The  dynamics  of  the  target  and  the 
weapon  delivery  approach  to  the  target  also  enter  into  the  avionics  system  requirements  because  of 
sensor  dynamic  limitations  and  computational  time  lags. 

Since  identification  of  the  target  may  be  the  major  driver  of  system  resolution  and  is  usually 
necessary  to  establish  tracking  as  soon  as  possible  after  detection,  the  system  maximum  resolution  will 
likely  be  designed  around  this  requirement.  In  all  cases,  however,  it  is  desirable  to  attempt  to  match 
the  resolution  requirements  to  system  needs  at  each  phase  of  the  mission.  The  resolution  requirement 
should  ho  mstohod  ro  the  mission  jha*e  to  a1]nw  fhe  pnf^ ntat loos  1  resources  ro  he  foruspd  n  .  «n  the 
solution  of  the  entire  problems  rather  than  on  a  limited  relationship  in  which  the  processing 
Inflexibility  generates  a  resolution  greater  than  required  by  the  system.  Resolution  should  be  adapted 
to  the  system  requirement  where  the  resolution  requirement  is  a  variable  throughout  the  mission  and 
computer  processing  determines  resolution. 

3.3  Mode  Determination  per  Mission  Segment 

A  variety  of  system  modes  are  required  to  accomplish  the  various  segments  of  the  missions.  These 
system  modes  place  modal  requirements  upon  the  avionics/sensors  supplying  data  for  the  modes.  These 
system  modes  are  driven  by  demands  and  constraints  placed  upon  the  system  by  the  engagement  environment, 
dJiuStam  I  w I  U t.  a-U'ftmma  L lul  1st  lose/ (■  h c*'  1 1  lllse ,  stlcttrs  t  laJiej  i  oo*f  -mpah  M  M  Lei,  »**  uu  i 
requirements,  and  pilot  deslres/abllltles.  The  successful  weapon  system  of  the  future  will  be  designed 
using  a  balanced  consideration  of  all  of  these  factors  to  provide  the  flexibility  necessary  to 
accomodate  all  segments  of  the  missions.  Based  upon  the  broad  functions  described  in  the  previous 
paragraphs  the  avlonlcs/sensors  are  required  to  provide  categories  of  data  which  become  system  or  sensor 
modes.  These  data  may  come  from  various  avionic  systems  individually  or  in  combination  as  dictated  by 
the  system  mode  demands  and  constraints. 

Both  radar  and  IR  ground  mapping  modes  as  well  as  system  modes  derived  from  combined  sensory  and 
stored  data  will  be  available  in  future  aircraft.  These  modes  will  permit  ground  mapping  for  day/nlght 
all:  veao.e.  ^a.isailun  a,.J  target  in^.  F-r  hi g,.  altitude  .a.lgativ..  the  terrvi..  map.  may  fta.e  coarse 
resolution  since  large  landmats  features  will  generally  provide  adequate  navigation  accuracy.  For  low 
altitude  navigation  the  resolution  requirements  will  likely  be  more  severe  since  the  terrain  masking  may 
severely  restrict  mapping  range.  This  masking  limitation  encourages  spot  mapping  for  correlation  with  a 
data  base  for  navigation  update.  Tne  processing  requirements  for  navigation  update  will  range  from  the 
simple  manual  position  fix  with  keyboard  Inputs  to  sophisticated  correlation  of  multiple  sensor  data 
with  a  stored  data  base.  In  a  single  mission  it  is  possible  that  both  high  and  low  altitude  navigation 
sagBwi  will  ootut.  T*u  i u  aii-jur  iftnt  mail  b«  aaapnbla  id  tu  w.i lgai  to*  ujm  Miciig  w  >i  * 
mission  and  the  special  requirements  of  each  mission  segment  must  be  met. 

Terrain  Following  and  Avoidance  allows  all  weather,  day/nlght  low  altitude  penetration  permitting 
the  aircraft  to  survive  in  enemy  territory  and  return  safely  to  fight  again  another  day.1^  This 
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capability  requires  frequent  terreln  data  inputs  fron  sensors  which  can  detect  the  terrain  contour  as 
well  as  Isolated  obstacles  such  as  redlo/tv  towers  and  electrical  power  lines  end  is  Influenced  by  the 
terrain  features,  enemy  defenses  and  the  mission  being  flown,  4  The  terrain  following  can  be 
mechanized  to  use  reel  time  data  from  e  multimode  sensor  to  generate  commands  to  the  aircraft  for 
malntelnlng  an  eltltude  offset  and  avoiding  ohstlcle.  Terrain  Avoidance,  however,  will  likely  require 
date  of  greater  range  than  available  from  the  real  time  sensor  data  being  generated  from  a  low  altitude 
In  hilly  or  mountelnous  country  since  terrain  masking  will  severely  limit  the  sensor's  range.  In  this 
case  a  stored  data  base  iugmented  with  real  time  sensor  data  Is  desirable. 15  The  choice  of  sensors 
will  be  dependent  upon  the  expected  sensor  performance  under  existing  conditions  and  the  availability  of 
the  sensor  to  provide  terrain  follow  or  avoidance  while  providing  other  modes  for  the  mission 
execution.  Since  safety  of  flight  Is  a  predominate  consideration  the  terrain  following  or  avoidance 
mode  will  have  priority  over  many  other  mission  modes  both  In  terms  of  sensor  selection  as  well  as 
Interruption  of  other  modes  for  terrain  data  collection.  This  will  require  cereful  sensor  management 
and  control  when  the  terrain  following  or  evoldence  mode  Is  exercised  In  conjunction  with  other  mission 
modes. 

Mission  variations  have  an  Impact  upon  target  detection  since  the  mission  will  establish  the 
eltltude  from  which  the  detection  must  take  place  and  the  maneuver  dynamics  which  occur  during  detection 
as  well  as  the  aircraft  velocity  during  detection.  In  a  typical  ground  target  engagement  the  delivery 
aircraft  will  be  likely  to  fly  es  low  and  as  fast  as  po-sible  taking  maximum  advantage  of  aircraft 
maneuvering  for  surviablllty. 

Searching  for  and  detection  of  targets,  whether  In  the  visual,  IR  or  radar  spectrum  relies  primarily 
upon  distinguishing  the  difference  between  clutter  or  beckground  noise  and  the  target.  Since  the  volume 
to  be  searched  In  a  finite  time  period  has  a  great  Impact  upon  the  system's  deta  processing 
requirements,  the  search  volume  must  be  matched  to  the  targeting  positional  unknowns  and  the  constraints 
Imposed  by  the  particular  mission.  The  low  altitude  mission  Imposes  severe  time  constraints  for  target 
search  ano  detection  requiring  a  minimum  of  deley  between  the  target  unmasking  and  detection.  This  In 
turn  restricts  the  search  aree  since  the  detection  delay  Is  essoclated  with  the  time  required  for  the 
scenner  to  pass  over  the  target  area.  This  Is  established  by  the  scan  pattern  and  dwell  time 
requirements  of  the  sensor.  The  dwell  time  requirement.  In  turn,  is  established  by  the  sensor  and 
target  signature  characteristics  and  the  data  processing  characteristics  of  the  detection  system. 

Mobile  target  detection  Is  simplified  If  ground  moving  target  Indication  (GMTI)  modes  are  employed. 
In  missions  which  Include  moving  targets  the  GMTI  can  greatly  Improve  target  detection  range  in  clutter 
by  Isolation  of  the  moving  from  non~moving  targets  or  background.  This  can  reduce  the  dwell  time  on 
terget  In  some  cases  thus  Improving  the  seerch  field  or  detection  delay  required,  thiz  may  also  reduce 
the  overall  resolution  requirement  for  detection  since  the  separation  of  target  from  clutter  or 
cencellatlon  of  fixed  targets  and  background  noise  allows  detection  of  moving  targets  without 
determination  of  target  detail.  The  low  altitude  mlsslcns,  as  In  the  case  of  search  and  target 
detection,  will  restrict  the  target  exposure  time  due  to  masking  by  terrain  feetures.  These  low 
altitude  missions  will  likewise  Impose  search  field  limitations  for  GMTI  at  high  velocity  since  dwell 
time  requirements  will  still  exist. 

When  detected  the  target  may  need  to  be  lurther  clesslfled  In  aome  missions  before  an  atteck  can  be 
made.  This  clesslf  lcatlon  may  range  fr<  a  recognition  by  the  target  location  to  e  more  complex 
recognition  due  to  specific  target  detail  characteristics.  Here  the  mission  requirements  will  strongly 
influence  the  target  recognition  mode  utilized.  Target  recognition  through  detailed  characteristics 
usually  requires  high  resolution  of  target  detail  demanding  long  dwell  times  and  extensive  data 
processing.  These  requirements  usually  restrict  area  of  coverage  end  frequently  stress  system  thoughput 
end  storage  capabilities.  Thus  simplistic  recognition  should  be  used  for  mlsslcns  where  detailed  target 
recognizers  are  not  warranted.  Multiple  source  deta,  data  from  more  than  one  onboerd  sensor  or  data 
linked  date  from  remote  sources,  may  provide  Information  which  will  allow  recognition  by  positional 
locetlon  rether  than  detailed  target  characteristics  thus  eeslng  the  onboard  processing  load.  For 
Instance,  moving  ground  targets  In  the  enemy  2nd  echelon  whether  trucks  or  tenks  may  be  vleble  targets 
needing  only  to  be  detected  In  thet  locetlon  identified  from  an  external  source  as  e  2nd  echelon  terget 
area.  By  contrast.  In  the  close  air  support  mission  It  might  be  necessery  to  distinguish  the  tenk  from 
a  truck  to  blunt  an  ongoing  offensive  since  destroying  the  truck  which  Is  trensportlng  support  equipment 
for  the  tanks  might  not  heve  as  greet  en  Immediate  Impact  on  the  battle.  The  mission  definition 
Influences  the  degree  of  recognition  desired  end  thus  the  recognition  mode  requirement. 

The  trecklng  requirements  for  elr-to-ground  targets  is  dependent  upon  the  mission,  weapon,  and 
target  characteristics.  Stetlonary  targets  which  are  larger  In  size  such  es  buildings,  bridges,  or  dams 
may  be  tracked  using  an  lnltlel  designation  by  the  pilot  on  the  heed-up  dlspley  or  on  e  sensor  dlspley. 
An  lnertlel  navlgetlon  system  updete  will  keep  the  elm  point  on  the  target.  A  moving  terget,  on  the 
other  hend  mey  require  precise  trecklng  since  It  has  the  cepablllty  of  changing  direction  or  position. 
This  may  require  an  automatic  trecklng  mode  which  Is  keyed  to  the  terget  extent  or  detell  within  the 
target. 

The  weapon  lmpect  upon  the  trecklng  requirements  Is  through  the  technique  It  uses  to  destroy  the 
target.  An  area  weepon  which  uses  a  large  number  of  submunitions  scettered  over  e  wide  area  to  echleve 
its  effect  requires  fer  less  from  the  weepon  dellvary  system  In  terms  of  tracking  then  e  laser  guided 
bomb  which  guides  on  e  leser  spot  creeted  by  the  weepon  delivery  system.  In  the  former  cesa  positional 
tvxutivj  ut  iv  ttttn  or  grmm  at  tla  its*  weapon  txuatft  in  atequtia.  In  m  tatter  can  a 
contlnuoua  track  from  weapon  launch  to  impact  may  be  necessary  with  accuracies  of  3  meters  or  less. 

Tho  alssion  requirements  In  terms  of  aircraft  delivery  altitude,  speed,  and  maneuver  constraints 
will  drive  those  target  tracking  requirements  associated  with  the  target  type  and  weapon  type.  The 
mission  planning  phase  will  of  course  consider  target  and  weapon  type  but  the  avionics  systems  must  be 
able  to  cope  with  the  dynamics  of  the  aircraft  In  delivery  for  the  weapons  system  to  benefit  from 
aircraft  performance  characteristics.  Furthermore,  the  avionics  system  should  be  adaptable  to  the 
target  and  weapons  types  to  permit  the  optimum  sensor  and  processor  utilization  during  weapon  delivery 
and  periods  of  maximum  stress.1' 

3.4  Consideration  of  Other  Aircraft  Missions 

Having  selected  the  alr-targround  attack  of  2nd  echelon  targets  as  the  typical  alssion  example  for 
this  doc  lament,  we  have  not  addressed  the  other  missions  which  will  be  encountered  by  an  all  purpose 
Bums  mix  ions  ittUte  On  UririU  «af  MUtfuatctasUun  simIou.  toMt  am 

Important  missions  and  warrant  e  brief  examination. 
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The  air-to-air  mission  is  one  which  will  be  a  part  of  the  overall  air-to-ground  mission  if  the 
air-to-ground  aircraft  has  self  defense  weapons  ai  !  is  responsible  for  its  own  anti-air  defense. 
Although  the  air-to-ground  fighter  would  prefer  the  air-to-air  engagement  on  the  return  leg  of  his 
mission  since  the  air-to-ground  weapons  would  have  been  expended,  the  air-to-air  engagement  could  come 
at  any  time.  Thus  the  avionics  must  be  configured  to  share  certain  air-to-ground  and  air-to-air  modes 
at  least  to  some  limited  degree.  The  major  requirement  is  the  ability  to  detect  the  enemy  airborne 
threat  and  establish  that  an  attack  is  eminent.  The  air-to-air  mission  may  dominate  when  the  threat  is 
perceived  to  be  real  and  evasive  action  is  not  desirable. 

Whether  the  air-to-air  mission  is  the  major  mission  or  evolves  as  a  part  of  the  air-to-ground 
mission,  the  avionics  must  provide  for  airborne  search,  detection  and  tracking  functions  necessary  to 
deliver  weapons  effectively  against  the  enemy  aircraft.  It  is  desirable  to  be  able  to  detect  the  threat 
during  air-to-ground  activity  before  he  has  achieved  a  detection  or  at  least  before  he  is  within  the 
range  at  which  he  can  launch  weapons.  After  conversion  to  the  air-to-air  mode  it  is  desirable  to  be 
able  to  search  and  crack  multiple  targets  simultaneously  as  well  as  to  provide  identification  of  all 
targets  in  the  arena.  The  identification  may  be  achievable  only  through  cooperation  with  other  aircraft 
or  from  ground  stations  although  it  is  highly  desirable  for  it  to  be  an  atonomous  non  cooperative  system 
if  achievable. 

In  the  transition,  when  completing  the  air-to-ground  activity  while  preparing  for  the  air-to-air 
engagement,  the  demands  upon  the  avionics  will  likely  be  at  a  maximum.  Although  the  enemy  may  not  time 
his  attack  to  permit  completion  of  the  air-to-ground  activity  before  the  air-to-air  engagement,  it  is 
desirable  to  be  able  to  perform  air-to-air  multi-target  search  without  abandoning  the  air-to-ground 
targeting  activity.  The  accomplishment  of  the  air-to-ground  mission  could  depend  upon  a  few  more 
seconds  of  air-to-ground  activity  while  observing  the  closure  of  the  airborne  threat.  The  management  of 
the  avionics  to  accomplish  the  simultaneous  air-to-air  and  air-to-ground  activity  is  a  major  task  which 
has  yet  to  be  achieved  in  a  current  fighter  aircraft. 

Another  complex  mission  from  the  standpoint  of  the  management  of  the  avionics  as  well  as  pilot  work 
load  is  the  strike/reconnaissance  mission  in  which  the  fighter  aircraft  is  required  to  search  the  battle 
area  for  targets  for  which  no  location  is  known  and  then  destroy  them.  This  is  an  extremely  difficult 
mission  because  of  the  desire  to  fly  low  for  survival  in  conflict  with  the  requirement  to  fly  at  an 
altitude  sufficient  to  detect  targets  over  the  terrain  masking.  It  Is  extremely  difficult  in  a  single 
seat  aircraft  since  a  pilot  has  little  time  to  interface  with  his  sensors  in  such  a  mission  because  of 
the  aircraft  flying  demands  for  a  survivable  engagement. 

The  reconnaissance  segments  of  this  mission  requires  periods  of  wide  area  searching  which  must  be 
accomplished  from  altitudes  sufficient  to  observe  the  possible  targets  over  the  terrain  mask.  Figure 
2-2  illustrates  the  Impact  of  terrain  masking  upon  aircraft  survivability.  If  we  assume  the  mission  is 
to  destroy  a  typical  gun  site  by  detecting  his  location  from  beyond  the  AAA  weapon  range  in  a  masking 
condition  of  6  degrees  (a  row  of  trees  10  meters  tall  at  100  meters),  the  searching  aircraft  must  fly  at 
300  meters  altitude  to  detect  the  gun  site  beyong  his  range  with  no  uncertainty  of  locati'”'.  »9SimJng  a 
2:1  range  uncertainty  the  altitude  increases  to  600  meters.  Both  altitudes  are  highly  undesirable  for 
survivable  attack  since  a  typical  surface  to  air  missile  or  another  AAA  gun  battery  with  the  same 
masking  constraint  could  be  launch  an  attack  against  the  flgher  if  within  3  kilometers. 

The  strlke/reconnaissance  mission  places  more  stringent  search  and  detection  demands  upon  the  sensor 
than  the  2nd  echelon  prebriefed  search  mission  used  in  the  previous  example  for  air-to-ground  target 
attack.  Ihi9  is  due  to  the  greater  detection  ranges  and  search  volumes.  If  self  defense  from  air 
attack  is  also  apart  of  this  mission  the  avionics  management  problem  grows  even  worse. 
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Figure  2-2:  TARGET  HASH  ANGLES  RELATED  TO  DEFENSIVE  WEAPONS  RANGE 
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4 .0  SENSOR  SELECTION 


Current  avionic  sensors  cover  the  full  frequency  spectrum  with  the  lower  frequency  systems  being 
primarily  cooperative  devices  while  the  higher  frequency  systems  are  autonomous*  Navigation  and 
communication  systems  such  as  LORAN,  the  Global  Positioning  System  and  JTIDS  can  be  used  for  aircraft 
positioning  and  location  of  cooperative  targets.  Higher  frequency  devices  such  as  radar,  radiometer, 
Infrared  and  televiaion  sensors  can  be  used  for  accurate  relative  position  measurements  as  well  as 
Improved  location  when  used  with  navigation  or  communications  systems.  Whatever  the  source  of  data  the 
avionics  system  must  be  capable  of  data  collection  in  battle  environment.  This  environment  often 
establishes  the  sensor  utility  for  providing  meaningful  data  during  th“.  various  mission  segments.  The 
sensor  selection  is  necessarily  based  upon  the  environmental  constraints  and  the  data  requirements  of 
the  weapon  system. 

Because  of  Its  ability  to  gather  data  at  night  and  under  Inclement  weather  conditions,  the  radar 
sensor  has  become  a  primary  avionics  subsystem  In  the  modern  fighter  and  bomber  aircraft.  Its  short 
cominga  Include  a  limited  resolution  in  bo ch  range  and  angle,  the  glint  and  the  specular  characteristics 
of  the  return.  It  has  good  long  range  capability  and  Is  adaptable  to  detection  of  moving  targets.  This 
makes  It  very  useful  as  detector,  tracker  and  (in  some  casea)  an  Identifier  of  both  airborne  and  ground 
targets.  Its  accurate  ranging  permits  terrain  following  measurement  and  air  to  ground  ranging.  It  has 
high  resolution  capability  but  may  require  significantly  long  looks  at  the  target  to  develop  this 
resolution  through  coherent  integration.  This  allows  radar  maps  geometrically  comparable  to 
photographic  raapa  to  be  generated  for  navigation,  position  update  and  targeting. 

Because  of  Its  ability  to  generate  vast  amounts  of  high  resolution  data,  the  radar  can  stress  the 
airborne  data  processing  capability.  For  that  reason,  the  mode  configurations  and  utilization  must  be 
closely  matched  to  the  mission  requirements  throughout  all  of  the  mission  segments  to  prevent  system 
overload.  The  radar  sensor  must  be  programmed  to  provide  timely  data  in  the  multiple  modes  executed  to 
fulfill  the  mission.  With  modern  digital  processing  the  radar  can  be  configured  to  provide  data  for  a 
wide  variety  of  modes.  With  electronic  beam  agility  the  radar  can  simultaneously  provide  navigation, 
terrain  follow,  target  tracking  and  weapon  guidance  functions  in  adverse  weather  and  at  night  when 
neither  the  unaided  pilot  nor  other  avionics  sensors  are  effective. 

The  target's  emissions  can  be  uaed  to  Identify  and  track  the  target  In  angle.  (Passive  range 
tracking  Is  possible  but  difficult).  This  allows  for  passive  attack  or  long  range  detection  If  the 
target  Is  emitting.  This  enhances  the  element  of  surprise  and  aids  in  detection  of  enemy  threats.  As 
In  the  case  of  radar,  the  passive  RF  sensors  have  day/nlght  all  weather  capability  and  can  be  big 
consumers  of  onboard  data  processing  capability  if  a  number  of  threats  are  present  or  the  non  target 
signal  density  is  great. 

Passive  RF  sensors  can  provide  data  unavailable  from  other  sensors  or  data  requiring  complex,  time 
consuming  proceaslng  when  derived  from  other  sources.  Because  the  angle  data  may  be  coarse  and  the 
range  data  time  consuming  to  generate,  the  passive  RF  sensors  may  work  best  In  conjunction  with  other 
sensors  rather  than  functioning  In  an  atonomoua  mode.  Proper  Integration  might  allow  these  sensors  to 
provide  long  range  target  Identification  and  tracking  as  fire  control  inputs  where  radiating  targets  are 
a  part  of  the  mission.  It  is  because  of  the  unpredictable  nature  of  the  periods  of  radiation  of  such 
targets  that  the  Integration  with  other  sensors  is  desirable. 

Many  missions  may  be  performed  In  areas  where  or  during  periods  when  the  weather  does  not  prevent 
the  use  of  infrared  sensors.  In  these  Instances  accurate  detection  and  angle  tracking  of  targets  Is 
possible  using  forward  looking  Infrared  sensors.  As  In  the  case  of  passive  RF  sensors  accurate  range 
tracking  Is  more  difficult  to  achieve.  Again  the  Integrated  sensor  system  approach  can  provide  range 
data  through  use  of  radar  or  laser  ranging. 

The  Infrared  systems  are  particularly  effective  when  detecting  active  targets  which  are  emitting 
heat  or  have  a  temperature  differential  with  respect  to  the  surroundings.  A  match  up  of  the  Infrared 
sensor  avionics  with  an  Infrared  guided  munition  is  usually  effective  since  both  should  work  well  In  the 
same  environment. 

Lasers  are  very  useful  for  ranging  and  target  Illumination  for  weapon  guidance.  For  target 
tracking  their  narrow  beam  allows  for  good  angular  tracking  and  their  short  pulse  capability  allows  for 
high  range  resulatlon.  For  target  illumination  the  beam  can  be  controlled  to  meet  the  spot  tracking 
guidance  requirements  of  the  weapons.  A  laser  radar  can  have  a  multiplicity  of  modes  slmlllar  to  those 
of  RF  radar  providing  In  some  cases  superior  performance. 

The  short  coming  of  laser  systems  Is  the  impact  of  the  atmosphere  upon  their  performance.  This 
limits  the  conditions  under  which  the  system  will  provide  suitable  range  performance  to  generally  fair 
weather.  This  of  course  limits  the  utility  of  lasers  as  a  single  sensor  In  many  mission  segments. 

When  used  with  other  sensors  In  an  integrated  system,  the  laser  can  provide  data  unavailable  from 
other  sources.  This  is  particularly  Important  in  short  range  engagements  both  air-to-air  and 
alr-targround  wnen  lasers  may  provide  more  usable  tracking  data  than  other  sensors.  As  one  element  of 
an  Integrated  multiple  sensor  target  Identifier  the  laser  Is  important  because  of  the  detail  It  can 
generate  about  the  target  which  has  a  different  Information  content  than  the  other  sensors. 

5 .0  SENSOR  INTEGRATION 

The  : tg-ttsl  t  has  a Vmt  •  ee-v.  lutlofl  kh  the  av-tu.te*  "lie  tnrt^ae 

processing  embedded  in  each  avionics  subsystem  Is  being  replaced  by  digital  processing  hardware  which  Is 
less  unique  between  subsystems.  In  fact  the  community  la  attempting  to  Impose  commonality  standards. 
As  digitalization  of  subsystem  function:  progresses  and  commonality  grows  the  opportunity  for  system 
peri..isan^e  Improvement  tt.ro^gf.  functional  lmegTsiton  will  naturall,  e.-l.e.  »*»-..!  t'.is 
integration  evolution  brought  on  by  the  computer  revolution  la  channeled  toward  achievement  of  the 
overall  mission  goals,  the  avionics,  airframe  and  weapons  must  be  thoughtfully  developed.  Sensor 
integration,  flight/fire  control  integration,  and  weapon/alrframe  Integration  are  the  key  areas  for  near 
term  effort.  This  discussion  focuses  upon  the  sensor  integration  and  its  major  elements  of  aperture 
sharing,  the  functional  relationships  and  the  processing  commonality. 

Because  the  radar  was  the  first  major  avionics  sensor  on  board  a  fighter  aircraft  requiring  as  much 
unobstructed  view  in  front  of  the  aircraft  as  possible  and  because  It  is  still  a  primary  sensor,  the 
prime  real  estate  in  the  airframe  (the  nose)  Is  usually  taken  up  hy  the  tire  control  radar.  The  radar 
designers  are  experts  in  convincing  the  world  that  they  can  always  use  a  larger  aperture  so  that  all 
challenges  for  nose  real  estate  are  defeated.  Aa  other  tensors  improve  and  radar  antenna  design  evolves 
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this  radar  dominance  will  subside-  Shared  aperture  concepts  will  emerge. 

What  are  the  driving  needs  for  aperture  sharing?  Visabllity  is  of  course  a  major  consideration. 
In  addition  there  are  no  displacemeot  errors  if  all  the  sensors  are  co-located.  Furthermore, 
stablization  can  be  simpler  since  there  may  be  less  movement  between  sensors'  boresight  lines  and 
a  tabulation  seasofS  If  all  ate  CJlv.a»toJ.  L.t«  for  tin.  Various  ochBvtS  sh„„ll  bt  ffiute  easily 
correlated. 

In  the  RF  bands  unique  methods  are  being  developed  which  permit  wide  band  signal  reception  in 
conjunction  with  active  radar  to  coexist  in  a  common  aperture.  This  permits  data  from  a  broad  range  of 
sources  to  be  easily  correlated  in  time  and  angle  with  the  radar  data. 

In  the  visual  and  IS  bands  unique  developments  have  provided  data  from  two  sensors  to  be  gathered 
simultaneously  with  a  common  mirror  system.  This  allows  easy  correlation  of  these  data  as  well  as  laser 
data  which  may  also  utilize  the  common  mirror  system  and  aperture. 

WSijy  the  ? mitt l petl- tf  the  are-  Ot lit- W  oav  I 

functions.  These  fuoctlons  can  be  performed  more  efficiently  if  common  techniques  are  applied.  This 
allows  for  effective  distribution  of  mission  tasks  between  sensors  as  well  as  coordinated  multiple 
fil  j-A.-t  Ujtj. 

Since  the  list  of  modes  each  sensor  can  perform  is  long  and  highly  overlapping  under  ideal 
conditions,  the  sensors  may  be  required  to  hand  off  tasks  which  can  be  more  effectively  performed  by  a 
sensor  which  is  not  as  fully  utilized  for  a  particular  mission  segment.  These  hand-offs  should  be 
configured  so  that  as  the  system  encounters  less  than  ideal  conditions,  the  tasks  can  be  handed  to  the 
sensor  providing  the  best  data.  This  may  require  a  redistribution  of  the  tasks  being  performed  by  that 

sensor  and  trade~off  between  sensors  of  the  mode  sharing  responsibilities  so  that  the  key  functions  are 

serviced. 

This  implies  systems  which  can  sense  performance  degradation  in  a  particular  sensor  and  which  can 
manage  emit  leauji  eS  to  oOluptnSate  for  these  pe,  iOLiudtuoe  dfegi  adatlou.  Tills  is  important  both  for  gOtu 
weapon  system  performance  as  well  as  safety  of  flight.  The  functions  must  be  managed  and  monitored  by 
each  sensor  system  as  well  as  managed  and  monitored  by  the  integrated  system  cootroller  be  it  manual  or 
automated.  Multiple  sensor  systems  of  the  future  which  function  in  an  integrated  fashion  will  utilize 
the  unique  characteristics  of  each  sensor  to  monitor  the  overall  performance  of  the  system.  This  will 
provide  the  data  necessary  for  the  various  system  modes  under  the  variable  environmental  conditions 
under  which  the  mission  is  executed. 

The  functions  provided  by  the  various  sensors  aboard  a  fighter  aircraft  are  shown  in  table  2-2. 
The  utility  of  these  sensors  la  dependent  ufx>n  tire  conditions  -inlet  Which  the  JitsAIon  Is  sting  petlofraed 

and  the  geometry  of  the  engagement.  These  are  the  functions  which  must  be  managed  in  the  integrated 

weapons  system. 

The  overlap  in  modes  available  for  the  various  sensors  shown  in  the  table  indicates  the  redundency 
of  processlog  required  within  the  weapons  system.  If  the  sensor  processors  are  autonooous  this 
redundancy  necessarily  exists.  The  integrated  sensor  processor  of  the  future  will  combine  many  of  these 
redundant  functions  by  using  common  processing  where  possible.  Some  redundancy  may  still  exist  since 
more  than  one  sensor  may  be  performing  the  same  function  during  transition  periods.  The  common 
graceasor  will  ar^nize  this  processln  so  that  these  redundant  processes  are  «rformed  more  efficiently. 

There  are  many  advantages  of  common  processing  even  without  one  computer  performing  all  like 
functions.  By  merely  having  like  processors  in  the  various  sensor  subsystems  the  common  functions  can 
be  serviced  with  common  software  which  will  reduce  system  design  time  and  Improve  the  understanding  of 
IM  .yjii-i  'f  owiitni.  w  a  *vl  repALi  wesenwi  (*.*'.<*  IT***  aft  Iw  ‘Jftumnt  <*.'  ItiMfa  sIsmlwj  io 
deal  with. 

For  those  functions  that  are  unique  to  a  particular  sensor  there  are  efficiencies  associated  with 
common  architecture  between  sensor  processors.  Here  again  the  malntainence  persoonel  will  more  readily 
understand  the  system  software  and  hardware  since  there  are  likely  to  be  many  simillarlties  in  these 
unique  functions. 

As  the  integrated  sensor  systems  emerge,  the  occasions  for  a  separate  expert  for  repair  of  each 

TABLE  2-2 

SENSOR  UTILIZATION  IN  THE  FIGHTER  MISSION 


Visual 


Radar 


-Target  Acquisition  and  Track 
-Navigation  &  INS  Update 
-Target  Identification 

-Weapon  delivery  via  HUD  or  in  cockpit  display 

-Target  Acquisition  and  Track 
-Navigation  Fixtaking  &  INS  Update 
-Map  Correlation  (DUiS) 

-Moving  Target  Indication  &  Tracking 
-Ranging 

-Weapon  Guidance 
-Aircraft  Guidance 
-Target  Identification 

-Target  Acquisition  and  Track 
-Image  Magnification  &  Identification 
-Navigation  Fixtaking  &  INS  Update 
-Map  Correlatioo 
-Ranging 
-Laser  Guidance 

-Threat  Warning  &  Avoidance 
-Target  Acquisition  and  Tracking 
-Target  Identification 


sensor  processor  begin  to  diminish.  Although  the  processing  associated  with  each  sensor  may  be 
separately  Identifiable  in  the  integrated  system  softwsre  and/or  hardware,  an  overall  understanding  of 
the  whole  system  becomes  of  greater  Importance  to  isolate  problems  In  modes  using  data  from  multiple 
sensors.  Common  computer  languages  such  as  Ada  are  emerging  and  will  help  to  provide  system  commonality 
of  processing.  Commonality  of  sensor  hardware  components  has  been  a  stated  goal  in  militsry  hardware 
for  many  years.  Commonality  of  processing  hardware  is  a  more  recently  stated  gorl.  Commonality  of 
software  is  as  yet  unachieved  and  will  require  several  more  years  of  “organization"  before  it  becomes  a 
reality  in  military  systems.  We  should  at  least  try  for  common  processing  within  the  systems  designed 
for  future  use.  Without  such  a  thrust  the  task  of  system  integration  becomes  very  difficult, 
inefficient,  and  in  all  likelihood  ineffective. 


6.0  IMPACT  OF  TECHNOLOGY 

Today's  digital  avionics  systems  are  but  just  a  beginning  of  the  technological  advances  to  become 
available  in  advanced  aircraft  of  the  future-  We  have  succeeded  in  the  conversion  of  many  analog 
avionics  devices  to  digital  devices.  The  next  step  is  to  upgt  ie  those  devices  to  take  advantage  of  the 
new  high  speed  digital  capability  which  has  emerged  in  the  1980's.'-® 

Twenty  five  years  ago  we  built  rooms  or  buildings  to  house  the  new  digital  computer  that  could 
compute  the  company  payroll  overnight.  Today  we  use  microscopes  to  design  the  devices  which  will  make 
up  computers  the  size  of  a  cigarette  pack  which  can  process  many  orders  of  magnitude  more  data.  This 
explosion  of  very  high  speed  integrated  circuit  technology  will  permit  the  future  avionics  sensors  to 
provide  msny  more  functions  of  greater  accuracy  and  reliability  than  exist  in  todays  most  advsnced 
fighters. 

The  programmable  signal  processor  (PSP)  of  the  1983  fighter  aircraft  radar  is  a  good  example.  The 
baseline  PSP  shown  in  Figure  2-3  is  availsble  today  for  performing  the  radsr  data  processing  functions 
necesssry  for  providing  the  rsdar  modes  in  a  present  era  fighter.  This  processor  is  cspable  of  a  wide 
variety  of  modes  including  multiple  target  track  while  search  for  sir-to-air  engagement  as  well  as 
terrain  following  for  low  level  penetration  for  air-to-ground  engagements.1^ 

As  very  high  speed  integrated  circuit  technology  becomes  availsble  in  the  latter  part  of  the  80's 
this  same  PSP  could  be  reduced  to  1/4  the  volume  while  still  maintaining  the  capability  to  process  the 
radar  data  of  the  current  PSP  (baseline).  As  shown  in  figure  2-4  the  power  requirement  would  be  reduced 
by  1/7  and  the  reliability  improvement  would  allow  an  Increased  expectation  of  mission  success  using  the 
advanced  PSP  over  the  present  configuration.  Acquisition  and  logistic  support  costs  would  be 
significantly  reduced. 

But  the  radar  will  likely  change  considerably  by  1990  so  thst  the  PSP  requirements  will  be  expanded 
to  accomodate  electronic  radar  beam  steering  ss  well  as  s  multitude  of  new  rsdar  modes  for  enhanced 
air-to-air  performance  ss  well  as  greatly  expanded  air-to-ground  capability.  Figure  2-5  indicates  the 
future  fighter  aircrsft  radar  PSP  characteristics  encompassing  the  greatly  expanded  capability  required 
for  the  advanced  tactical  fighters  of  the  1990's.  By  this  time  period  the  number  of  functions  per  chip 
will  have  increased  so  that  even  with  the  greater  processing  requirements  the  chip  count  is  more  thsn 


Chip  Count  •  5950 
No.  of  Board  Pairs  •  31 
Power/Voiume  •  2.8  kW  0.04  m3 

Signal  Processor  Capability 

-  16  MCOP  (COP  =  4  Muit,  6  Adds) 

GP  Computer  Capability 

-  1.3  MiP  (Dais  Mix) 

MTBF  (Fighter,  Non-inhabited)  • 

330  Hours 

Acquisition  Unit  Costs  •  100% 

Logistics  Support  Costs  - 100%  (3  Level) 
Probability  Mission  Success*  ■  .994 

Development  Cost  Factors  • 

-  None  (Baseline  Reference) 


*2  Hour  Mission 
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Figure  2-3:  STANDARD  1983  FIGHTER  RADAR  (BASELINE)  PROGRAMMABLE  SIGNAL  PROCESSOR  CHARACTERISTICS 
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*2  Level  Maintenance 
(No  Redundancy) 


(1)  Chip  Count  ■  600 

(2)  No.  of  Board  Pairs  -  6 

(3)  Power -400W 

(4)  Signal  Processor  Capability 

-  46  MCOP  (COP  =  4  Muit,  6  Adds) 

(5)  GP  Computer  Capability 

—  3  MIP  (Dais  Mix) 

(6)  MTBF  (Fighter,  Non-inhabited)  - 
2067  Hours 

(7)  Acquisition  Unit  Costs  •  33% 

(8)  Logistics  Support  Costs  •  9.3%  (2  Level) 

(9)  Probability  Mission  Success*  •  .9990 

(10)  Development  Cost  Factors  - 

-  Software  Reprogrammed  in  ADA 
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Figure  2-4:  BASELINE  PERFORMANCE  WITH  VERY  HIGH  SPEED  PROCESSOR 


(1)  Chip  Count  -  2200 

(2)  No.  of  Board  Pairs  - 17 

(3)  Power  •  1  kW 

(4)  Signal  Processor  Capability 

-  216  MCOP  (COP  =  4  Muit,  6  Adds) 

-  32M  BYTES  Memory 

(5)  GP  Computer  Capability 

-  6  MIP  (Dais  Mix) 

(6)  MTBF  (Fighter,  Non-inhabited)  • 

406  Hours 

(7)  Acquisition  Unit  Costs  •  66% 

(8)  Logistics  Support  Costs  •  48%  (2 
Level) 

(9)  Probability  Mission  Success*  -  .995 

(10)  Development  Cost  Factors  • 

•  Software 


*2  Hour  Mission 
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Figure  2-5:  1990  FIGHTER  AIRCRAFT  PROGRAMMABLE  SIGNAL  PROCESSOR  CHARACTERISTICS 


cut  In  half.  The  complexity  of  the  edded  redar  modes  will  significantly  Increase  the  cost  with  software 
developient  representing  e  mejor  cost  driver.  Historically  the  demands  of  the  mission  have  exceeded  the 
capability  of  the  weapons  systems  end  It  Is  unlikely  that  the  1990  fighter  would  contain  a  PSP  which  la 
of  much  less  capability  than  the  maximum  the  state  of  art  will  allow. 

The  enhanced  digital  proceaslng  capability  allows  revolutionary  rader  aystem  technology  to  emerge. 
The  major  rader  advancements  will  occur  in  the  area  of  beam  forming  end  control.  The  hardware  which 
creates  the  radar  beam  and  procesaes  It  In  the  tactical  fighter  of  the  90'a  will  likely  be  all  digital 
In  nature. 

Currently  the  beam  Is  formed  using  an  analog  transmitter  feeding  an  antenna  array  which  shapes  the 
beam  via  Its  mechanical  dimensions.  The  beam  la  positioned  with  gimbals  which  tend  to  move  slowly  and 
possess  a  great  amount  of  inertia.  The  fighter  radar  of  the  90' s  may  have  digital  beam  forming,  shaping 
and  positioning  mechanizations  with  antenna  arrays  made  up  of  a  large  number  of  digital  transmitting  and 
receiving  modules  which  are  controlled  from  and  feed  their  data  to  a  programmable  digital  signal 
processor.  Such  a  configuration  would  require  no  transmitter,  receiver  or  gimbals  as  we  know  them  In 
today's  radar  systems  since  all  of  these  functions  would  be  performed  by  the  digital  active  aperture 
antenna  modules. ^  The  beam  would  be  formed,  shaped  and  directed  electronically  by  solid  state 
devices  under  digital  control.  The  evolutionary  process  for  achieving  digital  active  aperture  radar 
capability  by  the  90' a  is  shown  In  figure  2-6. 

This  advanced  configuration  uill  permit  a  wide  variety  of  modes  to  be  structured  in  the  radar 
software  which  when  coupled  vith  the  high  speed  computational  capability  will  p-ovlde  a  full  complement 
of  atr-to-alr  and  air-to-ground  modes  to  be  executed  In  an  Interleaved  fashion.  This  will  permit  a 
variety  of  wave  forma  and  beam  positions  to  be  generated  during  a  single  PRP  for  multiple  mode  data 
collection  simultaneously.  This  will  greatly  enhance  the  weapon  system  performance  and  mission 

flexibility  of  the  advanced  tactical  aircraft. 

As  the  digital  active  aperture  radar  evolves  several  Intermediate  systems  may  be  developed.  Agile 

beam  technology  has  already  been  demonstrated  for  bomber  application  and  may  be  available  for  fighter 

application  within  a  year  or  less.  As  the  very  high  speed  data  processing  become  available,  advanced 
modes  will  become  possible  for  both  glmballed  and  electronically  agile  radars.  Hybrid  monolithic  active 
aperture  technology  may  be  available  in  the  late  80' s  to  provide  the  digital  receiving  array  flexibility 
for  interpulse  receive  mode  Interleaving  as  en  Interim  to  the  fully  digital  active  aperture  rader 

capability.  Eech  of  these  steps  offer  significant  system  Improvement  end  will  develop  software  modes 
which  are  applicable  to  future  systems  as  the  reder  technology  advances. 

The  technology  of  lasers  useful  for  tactlcel  aircraft  application  has  been  evolving  repldly  In  the 
past  decade.  Lasers  useful  for  renglng  and  Illumination  for  weapon  guidance  made  their  debut  during  the 
late  60' s.  In  the  70' s  the  airborne  lasers  were  considered  for  broeder  roles  of  navigation,  terrain 
following  es  well  as  multiple  missile  guidance.  As  we  progress  through  the  80' s  the  use  of  lasers  to 
provide  many  of  the  classical  radar  functions  for  air-to-ground  weepon  delivery  will  emerge.  The  lasers 
are,  of  course,  limited  by  environmental  factors  such  as  fog,  haze  and  smoke  but  since  they  are 
complimentary  to  conventional  radar  sensors  and  provide  highly  accurate  air-to-ground  as  well  as 
air-to-air  pointing  and  tracking,  lasers  are  being  highly  regarded  as  an  element  of  a  multiple  sensor 
system  for  the  complex  missions  of  the  future. 
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Figure  2-6:  FIGHTER  RADAR  EVOLUTION 
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During  the  early  days  of  laser  development  the  emphasis  focused  around  1.06  micron  region  for 
target  designators  and  laser  rangers.  This  was  compatible  with  TV  optics  and  could  be  coupled  through 
the  same  optical  chain  as  the  TV  Image  to  facilitate  laser  alignment.  Current  efforts  are  more  heavily 
focused  In  the  10.6  micron  region  for  better  weather  performance  and  compatibility  with  forward  looking 
Infrared  systems  operating  In  the  8-12  micron  region.  It  Is  in  this  region  that  the  significant 
developments  In  laser  systems  for  the  fighter  aircraft  of  the  90's  are  likely  to  occur. 

The  C02  lasers  can  provide  navigation,  target  detection,  target  classification,  accurate  pointing 
and  tracking  for  weapons  control  as  well  as  terrain  following  and  obstacle  avoidance.  Since  the  laser 
system  Is  compatible  with  the  radar  system  In  the  data  It  generates  as  well  as  the  format  In  many  cases, 
the  two  systems  can  be  used  in  supportive  roles  In  the  Integrated  system.  Both  the  CO2  laser  and 
radar  can  provide  reliable  data  for  the  conditions  (weather,  smoke,  etc.)  encountered  In  a  high 
percentage  of  the  missions.  When  these  conditions  degrade,  the  Impact  on  the  laser  systems  differs  from 
radar  systems.  Thus,  the  compatibility  changes  from  the  selection  of  either  sensor  for  distribution  of 
the  mission  tasks  between  the  sensors,  to  a  selection  of  the  best  source  of  data  for  the  existing 
condition.  This  will  allow  the  C02  laser  to  be  used  during  certain  rare  periods  where  rainfall 
degrades  the  rsdar  and  the  radar  to  be  used  where  fog  restricts  the  CO*  laser  system.  Weapons  with 
guidance  systems  operating  In  the  laser  bands  will  of  course  be  matched  with  the  laser  sensor  systems 
for  comparability  of  conditions  under  which  the  mission  can  be  successfully  executed. 

A  typical  performance  curve  for  a  laser  functioning  In  the  terrain  following  mode  Is  shown  in 
figure  2-7.  For  a  system  which  has  a  7dB  signal  to  noise  the  sensor  could  provide  a  5  kilometer 
capability  in  haze  dropping  to  about  3.3  kilometers  in  fog.  This  latter  number  being  near  the  minimum 
range  for  safe  high  speed  low  level  flight. ^ 

Imaging  infrared  sensors  offer  enhanced  fighter  weapon  delivery  performance  by  providing  both 
targeting  and  navigation  data.  In  the  1980's  it  is  likely  that  these  sensors  will  be  more  heavily 
Integrated  into  the  fighter  avionics  suite  for  enhanced  weapons  system  performance.  To  date  these 
systems  have  been  mounted  In  pods  to  aid  In  aircraft  reconfiguration  for  specialized  missions  and  to 
maximize  the  coverage  of  the  sensors  on  airframes  In  which  the  nose  Is  committed  to  other  sensors 
(radars).  By  the  1990’s  these  IR  sensors  will  have  moved  to  within  the  airframes  of  operational 
fighters  and  will  providing  multiple  mode  inputs  for  the  integrated  fighter  control  systems.  This  may 
impose  multiple  field  of  view  requirements  on  the  IR  system  as  shown  In  table  2-3,  which  provide  the 
variable  sensing  requirements  of  the  full  mission  with  a  sensitivity  to  0.1°C.  This  will  yield  a 
typical  targeting  system  performance  as  shown  in  figure  2-8.  The  major  improvements  In  the  80's  will 
come  from  the  detector  technology  which  will  provide  cooled  photo  conductive  arrays  with  the  high 
senslvlty  necessary  to  meet  the  navigation  requirement.  These  systems  will  be  compact  and  reliable  with 
digital  output  for  direct  interface  with  the  system  processor  and  other  digital  avionics.  This  enhances 
the  ullllty  of  the  Imaging  IR  as  an  important  element  In  an  integrated  sensor  system.  The  Imaging  IR 
whan  coupled  to  a  CO2  laser  will  provide  functions  such  as  navigation  Including  INS  update,  air-to-air 
search,  ait-torground  target  search,  moving  target  detection,  target  tracking,  target  identification  and 
missile  guidance.  As  in  the  case  of  the  CO2  laser  the  compatibility  between  the  IR  and  radar  will 
allow  mode  sharing  between  the  sensor  systems  under  favorable  weather  conditions  and  a  hand-off  to  the 
sensor  providing  the  better  data  under  degraded  condition. 


Figure  2-7 1  COj  USSR  KANGS  PERFORMANCE  PREDICTION  IR  TERRAIN  FOLLOWING  NODE 


Table  2-3  PERFORMANCE  PARAMETERS  FOR  IMAGING  INFRARED  SYSTEM 


TARGETING  FLIR 

NAV  FLIR 

Effective  focal  Length  (cm) 

20.3 

10.2 

2.2 

Field  of  View  (Deg) 

2.25  x  2.25 

4.50  x  4.50 

21  x  28 

Aperture'  cm)  4.0 

10.2 

5.1 

1.1 

fit 

f/2.0 

f/2.0 

f/2.0 

Transnission 

0.49 

0.46 

0.62 

Instantaneous  Field  of  View  (Mrad) 

0.15  x  0.245 

0.308  x  0.492 

1.43  x  2.29 

Spectrum  (microns) 

8.1  -  11.5 

8.1  -  11.5 

8.0  x  11.5 

Detector  (mils) 

1.25  x  320 

1.25  x  320 

1.25  x  320 

Aspect  Ratio 

1  x  1 

1  x  1 

3x4 

DETECTION 

<\  -  0  ») 


RECOGNITION 
(N  -  O  S) 


RANGE  KM 
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Figure  2-8:  FtIR  AIR-TO-GROUND  RANGE  PERFORMANCE 
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7.0  CONCLUSIONS 

Tactical  weapon  delivery  systems  for  future  tactical  aircraft  must  be  strongly  Influenced  by  the 
target  characteristics,  their  environment  and  deployment,  and  by  the  weapons  and  tactics  required  to 
destroy  these  targets.  The  result  is  an  Integrated  avionics  system  which  exploits  the  flexibility 
inherent  in  digital  technology  and  is  Integrated  in  function  not  just  in  hardware.  To  arrive  at  such  a 
system  architecture  requires  a  methodical  assessment  of  the  tactical  requirements  to  translate  them  into 
functional  requirements  from  which  a  true  integrated  system  architecture  can  be  consummated. 
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DISCUSSION 

K.F.Boecking,  Ge 

In  Table  2-A,  it  is  shown  that  during  ground  attack  the  function  TF/TA  has  a  priority  of  1  in  the  mission  segments 
search/acquisition  and  attack/guidance.  Would  you  please  explain  why  the  functions  ground  T/D  and  T  and  weapon 
delivery  have  a  priority  of  4  only  considering  that  these  functions  were  the  reasons  for  take-off? 

Author’s  Reply 

The  reason  for  assigning  TF/TA  priority  No,  1  during  all  low  altitude  mission  segments  is  because  of  the  impact 
upon  flight  safety.  Likewise,  the  system  monitoring  function  must  have  high  priority  (No.  2)  since  it  determines  the 
quality  of  the  TF/TA  inputs  for  the  system,  thus  the  function  is  also  key  to  flight  safety.  Navigation  is  a  function 
that  is  always  present  throughout  the  missions  and  although  the  sensor  suite  of  the  aircraft  may  be  fully  occupied 
for  a  short  period  providing  weapon  delivery,  a  fu"  awareness  of  where  the  aircraft  is  and  where  it  is  headed  must  be 
maintained.  Thus,  the  weapon  delivery  priority  of  4  dunng  attack  and  weapon  guidance  means  that  it  will  be  pre¬ 
empted  if  problems  arise  in  the  other  3  functions  even  though  it’s  the  primary  task  during  that  mission  segment.  A 
degraded  mode  in  the  event  of  TF/TA  failure  might  be  to  fly  at  a  higher  altitude  if  tactically  feasible.  This  would 
faist  priority  cf  wcapor.  dfcftvery  unfii.g  tfts  mission  scgfiicuTS  tciascu  l  -weapon  Jcnraj . 
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OPERATIONAL  READINESS  AND  ITS  IMPACT  ON 
FIGHTER  AVIONIC  SYSTEM  DESIGN 


by 

J.F.lrwin 

NORTHROP  CORPORATION 
Aircraft  Division 
Hawthorne,  California  90250 
USA 

I.  ABSTRACT 

Operational  Readiness  (OR)  is  a  widely  used  term  that  covers  various  aspects  of  availability, 
maintainability,  reliability  and  testability. 

Just  as  the  development  of  avionic  systems  require  the  establishment  of  system  engineering,  soft¬ 
ware  design  and  interface  management  guidelines,  the  same  requirement  exists  for  the  world  of  operational 
readiness.  These  OR  guidelines  include  the  following  controllable  elements: 

Design-for-Testability  (DFT), 

Operational  Fault  Tolerance, 

System  Diagnostic  i  Reconfiguration, 

Post-Flight  Data  Extraction/ Analysis,  and 

Integrated  Test  &  Maintenance. 

Design  and  Acquisition  of  systems  and  prime  electronic  equipment  must  account  for  early  considera¬ 
tion  of  testability  and  automatic  test  design  requirements.  Testability  factors  influence  all  phases  of 
design,  integration,  deployment  and  support  of  electronic  equipment  and  will  adversely  impact  weapon 
system  availability  and  ultimate  return  on  investment  if  improperly  specified  and  implemented. 

The  major  goals  of  fault  tolerant  systems  are  increased  weapon  systems  availability,  mission  sur¬ 
vivability,  snd  an  affordable  life  cycle  cost.  Widespread  acceptance  of  operational  readiness  objectives 
will  probably  be  predicated  on  the  demonstrated  life  cycle  cost  of  those  initial  aircraft  containing  fault 
tolerant  systems. 

New  technologies,  such  as  Very  Large  Scale  Integrated  (VLSI)  and  Very  High  Speed  Integrated 
Circuits  (VHSIC),  will  have  a  major  impact  on  tomorrow's  operational  effectiveness,  provided  the  OR 
concepts  are  clearly  defined  and  enforced.  Processing  elements,  virtual  memory  techniques,  and 
wideband  buses  are  readily  available  for  the  next  generation  fighter.  The  design  of  weapon  system 
computers  capable  of  tolerating  random  hardware  failures,  has  become  a  relatively  mature  technology  at  an 
affordable  cost.  However,  full  advantage  must  be  taken  of  advances  in  computer  technologies  to  integrate 
a  fault  tolerant  design.  Today,  adequate  methods  exist  to  insure  a  high  degree  of  availability  and 
mission  success  through  simple  Bullt-In-Test  (BIT)  and  auto-reconflgurable  designs.  This  paper  provides 
a  managerial  and  technical  roadmap  for  accomplishing  the  desired  operational  readiness  goals  in  the  next 
genevatlon  fighter.  The  contribution  of  the  various  attributes  (including  testability,  avionic  architecture, 
fault  tolerant  designs,  BIT,  standardizstion  and  operational  readiness  control)  is  provided. 


II.  TESTABILITY  AND  ITS  APPLICATION 

Current  projections  of  computer  technologies  indicate  a  strong  trend  toward  reduced  avionic  size, 
weight  and  cost,  as  well  as  greatly  improved  weapon  system  availability  and  support sbillty.  The  com¬ 
plexity  of  fighter  avionics,  however,  will  remain  high  as  more  and  more  mission  functions  are  accommo¬ 
dated  by  the  weapon  system. 

Projected  trends  In  topography  and  packing  densities  of  electronics  work  to  the  advantage  and 
relative  ease  of  partitioning  circuitry  for  purposes  of  real-time  testability.  This  Is  made  possible  by  the 
integration  of  much  higher-level  functions  on  a  single  chip.  Tnere  is  no  longer  a  need  to  worry  about 
the  failure  modes  of  a  single  flip-flop,  NAND  gate  or  the  like,  now  that  the  avionics  can  be  reduced  in 
weight  and  volume  by  an  order  of  magnitude  over  that  of  the  second  generation  electronics  (See  Fig¬ 
ure  1).  Ample  built-in-test  and  redundancy  can  be  Incorporated  at  the  system  and  equipment  level  to 
achieve  the  desired  degree  of  operational  as  well  as  depot  level  testability.  Function  for  function,  the 
cost  of  VHSIC  over  that  of  a  hybrid  circuit  (i.e.,  discrete  and  MSI),  even  with  testability  added,  will  be 
reduced  significantly. 

The  design-for-testability  (DFT)  discipline  is  not  black  magic.  Traditionally,  however  it  has  been 
an  area  often  ignored  by  most  operational  design  engineera.  This  lack  of  interest  in  DF.  characteristics 
of  the  system  (and  subsystem)  is  the  natural  consequence  of  neither  the  market  place  nor  supplier  self- 
interest  in  placing  DFT  high  on  the  list  of  design  trade-off  priorities.  DFT  is  now  emerging  in  a  manner 
reminiscent  of  the  Reliability /Maintainability  (R/M)  groundswell  of  the  not  too  distant  past.  And  as  with 
R/M,  the  detailed  effective  implementation  of  DFT  is  primarily  the  function  of  the  design  engineering 
process.  In  a  similar  manner,  the  design  engineering  process  requires  inputs  end  oversights  of  DFT 
design  requirements  and  validation  by  system  engineers  dedicated  to  the  DFT  discipline. 
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(n)-  DESIGNATES  ELECTRONIC  CIRCUIT  GENERATION 

FIGURE  1.  ELECTRONIC  VOLUME  &  DENSITY  CHANGES 


Design-for-testability  must  accommodate  all  levels  of  test  and  repair.  The  degree  or  utilization  of 
testability  is  largely  determined  by  the  maintenance  level  being  considered.  Built-In-Test  (BIT)  and 
performance  monitoring  is  used  at  the  Operational  level  and  provides  for  a  quick  readiness  status  and 
fault  isolation  to  major  subsystems  or  units  within  the  system.  Testability  at  the  Depot  maintenance  level 
relates  to  unit  testing  and  the  application  of  off-line  Automatic  Test  Equipment  (ATE)  and  special  test 
devices . 

Intermediate  Level  maintenance  in  support  of  future  avionics  will  be  relegated  largely  to  a  flight  line 
removal  and  replacement  function. 

The  Operational  readiness  concept  for  avionics  must  include  provisions  for: 

1.  Design-for-Testability  (DFT) 

2 .  Operational  Test 

3.  Integrated  Test  k  Maintenance  (ITkM) 

These  OR  features  or  attributes  are  better  identified  in  Figure  2,  which  provides  amplification  of  these 
specific  OR  categories  of  design.  The  concern  is  that  an  approach  be  implemented  such  that  each  of  the 
interdependent  elements  of  OR  be  integrated  into  the  total  weapon  system  design.  To  properly  apply 
these  disciplines,  the  system  definition  must  provide  for  early  identification  of  issues  such  as: 

1.  Availability/Reliability  Requirements 

2 .  Level-of-Repair 

3.  Testability  Standards  k  Guidelines 

4.  Built-in-Test  Features  (Hardware  k  Software) 

5.  Functional  Circuit  Partitioning 

6.  Fault  Isolation/ Avoidance 

7 .  Accessibility 

8.  Weight  k  Volume  Considerations 

9.  Integrated  Logistics  Support 


10.  Life  Cycle  Cost  Impact 


Unfortunately,  the  tendency  has  been  to  treat  each  of  the  features  (i.e.,  DFT,  Operational  Test 
and  ITiM)  of  the  OR  weapon  system  attributes,  independently  of  each  other  with  little  or  no  compatibility 
relative  to  system  objectives.  The  criticality  of  this  total  integrated  maintenance  concept  cannot  be 
over -emphasized .  Tlit  impact  of  designing  the  avionics  with  adequate  t>lf  without  eoifsidtiiiig  toe 
influence  on  the  ATE  design  or  onboard  operational  tests  would  neither  be  a  sound  nor  a  cost-effective 
strategy.  Therefore,  a  model  of  the  life  cycle  maintenance  concept  must  be  developed  for  the  weapon 
system  under  consideration  and  it  must  be  properly  implemented  and  managed  across  all  phases  of  design 
development  and  test. 


DESIGN  FOR  TESTABILITY  OPERATIONAL  TEST 


INTEGRATED  TEST  AND  MAINTENANCE 


•  TESTABILITY  STANDARDS 

•  BUILT-IN-TEST 

•  REDUNDANCY  DESIGN 

•  CIRCUIT  DESIGN  AND 
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•  TEST  POINTS/CONNECTORS 

•  ATE  COMPATIBILITY 


•  INFLIGHT  PERFORMANCE 
MONITORING  SYSTEM 

•  SYSTEM  DIAGNOSTICS 

•  FAILURE  MODE 
REVERSIONARY 
PROCESSES 

•  FAULT  CONTAINMENT 
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•  AUTOMATIC  TEST  SYSTEMS 

•  CALIBRATION/ALIGNMENT 

•  PREVENTIVE  MAINTENANCE 

•  LOGISTICS  SUPPORT 


FIGURE  2.  ACHIEVEMENT  OF  OPERATIONAL  READINESS  ENCOMPASSES: 


Future  weapon  system  designs  must  consider  the  total  aircraft  testability  design  as  depicted 
functionally  in  Figure  3.  A  synergistic  approach  is  necessary  as  a  result  of  the  highly  integrated  nature 
of  advanced  fighter  technologies  which  include  provisions  for  (1)  solution-oriented  tactical  situations 
requiring  instantaneous  aircraft  maneuvering  (e.g.,  Terrain  Following/ Terrain  Avoidance  (TF/TA),  (2) 
missile  avoidance,  (3)  optimum  coordinated  attack  profiles  (air-to-air)  and  (4)  overall  energy  management 
and  thrust  vectoring.  Any  one  of  the  system  elements  must  exhibit  a  degree  of  fault  tolerance  or  grace¬ 
ful  degradation  (failsoft)  which  for  any  one  failure  will  provide  for  a  reasonable  guarantee  of  mission 
success  without  major  degradation  or  loss  of  aircraft. 

General  Bernard  Schriever  once  said,  "Many  times  we  have  found  that  the  pacing  factor  in 
acquiring  new  weapons,  support,  and  command  and  control  system  is  not  the  technology,  ...  it  is 
management . "  Furthermore,  weapon  systems  management  often  does  not  excel  in  all  aspects  of  the  air¬ 
craft  technologies  (i.e.,  Avionics,  Flight  Controls,  Air-vehicle,  and  Propulsion)  as  well  as  the  integration 
of  the  operational  and  test,  concepts.  The  tendency,  therefore,  is  not  to  give  equal  consideration  to 
these  weapon  system  elements  in  a  holistic  fashion;  consequently,  the  objectives  of  availability,  operational 
performance,  and  life  cycle  cost  have  been  compromised. 


III.  AVIONIC  SYSTEM  ARCHITECTURES 


The  advanced  avionic  system  architectures  of  today  utilize  digital  multiplex  buses  with  inter¬ 
connected  multiprocessor  subsystems  dedicated  to  specific  functions  such  as  navigation,  communication, 
weapon  delivery,  controls  and  displays,  stores  management,  and  target  acquisition  (Figure  4).  More  and 
more,  software  is  assuming  the  traditional  functional  role  previously  allocated  to  the  hardware  design. 
Newly  proposed  avionic  designs  also  emphasize  integration  of  flight  and  fire  control  as  well  as  propulsion 
control.  Redundant  avionic  buses  are  utilized  to  provide  a  backup  path  for.  communications  and  navi¬ 
gation  functions  in  the  event  the  primary  communication  interface  should  fail.  '  There  still  exists  a  wide 
diversity  of  second  order  architectures  and  related  allocation  of  functions  to  the  various  distributed 
processors.  The  processors  embedded  in  the  various  subsystems  arc  quite  dissimilar  in  design,  capa¬ 
bility,  language,  timing  and  testability.  Today's  avionics  incorporate  these  multiprocessor  designs  by 
specifying  compliance  with  a  common  interface  design,  such  as  that  defined  in  MIL-STD-1553B.  This 
trend  toward  distributed  architectures  is  aided  by  the  many  tri-service  studies  which  have  supported 
lr.Juatry  In  Jcftnti.g  this  ti.JVat._e .1  teil.t.-Lgy.  li.wt.v_r  ,  Lc>  wfil  SILA,  .it  tuA  at.  J  tuiuv 

consideration  for  manual  system  reconfiguration  by  the  pilot,  little  has  been  accomplished  in  the  way  of 
automatic  operational  fault  tolerance  and  reconfiguration  of  mission  elements. 

With  the  advent  of  the  advanced  avionics  architectures  comes  the  need  for  equally  advanced  tools  to 
model  the  fault  tolerant  requirements  and  to  establish  affordable  designs.  Such  models  as  the  Markov  and 
ARIES  81  models  are  serving  to  accomplish  these  goals.  However,  considerable  sophistication  must  be 
cu  jvo  tv  -x.stn.g  CAi>  (Cuuipnrvr  AKteJ  iftsignj  progvcnijs  to  toiuw  fur  ctwupltmieTriary  ..m,  Tuatl_  -fJerinrtron 
of  testability  designs.  Such  models  would  also  account  for  increase  in  component  counts,  reliability 
factors,  physical  budgets  (weight,  size,  cooling),  timing  budgets  and  cost. 
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FIGURE  3.  PILOT/AIR  VEHICLE  AND  INTEGRATED  AVIONICS  SYSTEM 
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FIGURE  4.  DISTRIBUTED  SYSTEM  CHARACTERISTICS 


IV.  FAULT  TOLERANT  DESIGNS 


Concepts  being  investigated  for  future  use  in  fault  tolerant  design  include  continuous  automatic 
reconfiguration,  software  implemented  fault  tolerance,  and  the  use  of  functional  redundancy  in  failure 
detection.  The  fault  tolerant  design  for  the  future  will  strike  a  middle  ground,  borrowing  ideas  from  all 
available  technologies.  For  example,  a  certain  degree  of  hardware  redundancy  together  with  reliance  on 
software  to  provide  functions  such  as  fault  isolation,  diagnosis,  and  error  detection  and  recovery  will 
pwjuU  In  (T#  umsjl  ftWttl  awni  uf  ihiiirin-^  nutfium*  Tfc*  tm*  uf  1  urjitticiiaJ  radTitUklug . 

which  is  typically  inherent  in  the  system  design,  can  vastly  reduce  the  need  for  hardware  redundancy. 
For  example,  the  pitot-static/air  data  systems  do  not  have  to  be  duplicated  to  verify  that  correct  indi¬ 
cated  airspeed  is  being  generated.  Instead,  an  algorithm  can  be  employed  using  the  known  values  of  air- 

Ciaft  ii,aoo,  dlrcidfl  . efex-eiiie  a^eu,  ah gle  JT  attack,  i ami  acu^le^aliou,  and  .ciatcu  coIiSTants  To  cuujpuTe 

indicated  airspeed  for  the  purpose  of  verification.  Primary  factors  which  will  influence  the  fault  tolerant 
design  and  which  must  be  considered  in  the  acquisition  of  electronic  systems  and  components  are  listed 
below : 

1.  SfSXcii.i  SlftsywetTi  AFMiileKBft 

2.  Redundancy  Management  Criteria 

3.  Degraded  Modes  Operations 

4.  Fault  Detection  Techniques 

a.  Comparison 

d.  Redundancy  Voting 

c.  Periodic/ Initiated  Testing 

d.  End-to-End/Diagnostics 

e.  Event  time-out 

5.  Fault  Isolation  and  Containment 

a.  Functional  Partitioning 

b.  Independent  Operation 

c.  Logical  Modeling 

6.  Recovery  (Coverage) 

a.  Error  Masking 

b.  Error  Detection  and  Correction 

c.  Reconfiguration 

d .  Retry 

7 .  Tolerance  Renewal 

8.  Environmental  Constraints 

9.  Cost  and  Development  Constraints 


V.  EXTENT  OF  BUILT-IN-TEST 


The  implementation  of  BIT  in  avionics  is  usually  predicated  on  availability  requirements  which 
provide  limits  on  the  mean-corrective-maintenance-time  at  the  Organizational  Level.  The  fault  isolation 
level  of  BIT  is  determined  on  the  basis  of  functional  modularity,  accessibility,  spares  provisioning,  repair 
skills  of  maintenance  personnel  and  planned  off-line  test  equipment. 

A  design  for  BIT  optimization  is  favored  over  the  more  costly  ATE  approach.  The  mobility  of 
military  forces  is  such  that  complex  ATE,  with  its  associated  adapters  and  support  equipment,  is  less 
desirable  than  a  comprehensive  approach  to  operational  BIT. 

The  cumulative  effect  of  all  elements  impacting  the  BIT  trade-off  analysis  must  be  weighted;  they 
include  such  factors  as; 

1.  Development  and  life  cycle  support  costs 

2.  Impact  on  availability/ reliability 

3.  Level  of  isolation  afforded  in  terms  of  ambiguity  ratios 

4.  Impact  on  weight,  size  and  access 
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5.  Impact  on  environmental  conditions  (e.g.,  cooling,  EMI,  shock) 

6.  Added  power  requirements 

Further,  BIT  must  be  traded  off  with  the  established  testability  philosophy  and  the  selected  ATE. 
When  ATE  provisions  are  sufficient  for  total  off-line  maintenance  support,  extensive  BIT  may  not  be 
necessary.  The  U.S.  military  would  prefer  to  remove  a  Shop  Replaceable  Unit  (SRU),  rather  than  an 
electronic  unit  or  subsystem  at  the  Operational  level.  Thus,  the  avionics  design  concept  and  maintenance 
philosophy  must  allow  for  unambiguous  isolation  to  the  card  level.  At  the  same  time,  the  weapon  system 
design  concept  must  allow  practical  flight  line  access  to  the  failed  card.  The  Operational  test  software 
must  be  compatibly  interleaved  with  the  operational  flight  program  in  order  to  support  this  philosophy. 

ftoc  rtnpfistring  nua  oil  approach  is  XtuA&moaiA  ro  uesigiieQ  rlit  onghoA  uViuhics,  ttnA  i-igurrt  4, 
provides  a  representation  of  the  hidden  areas  for  consideration.  A  master  plan  with  the  appropriate 
maintenance  philosophy  and  design-for-testability  specifications  must  be  established  early  in  the  planning 
phases.  Standardization,  packaging,  environmental  constraints,  acceptance  criteria  and  the  like  must  all 
be  firmly  established  and  disseminated  to  the  affected  design  organizations. 


The  Organizational  Level  tests  must  be  properly  fused  with  the  execution  of  the  operational  func¬ 
tions  such  that  minimum  vigilance  and  manual  reconfiguration  is  required  of  the  pilot.  Detection,  isolation 
and  the  self-healing  processes  will  generally  be  transparent  to  the  pilot  with  alerts  and  cues  provided 
after  the  fact.  Figure  6  provides  an  architecture  test  philosophy  which  illustrates  this  concept.  The 
pilot  will  have  a  choice  of  accepting  the  systems  failure  mode  recovery  or  of  selecting  an  alternate,  if  one 
exists.  Aircraft  safety  and  mission  success  will  continue  to  be  the  motivating  factors  in  selecting  the 
automatic  or  manual  modes. 

Specific  approaches  to  avionic  BIT  designs  might  include  on-chip  testability  with  monitor  circuits 
added  for  failure  detection  and  circuit  feedback,  summing  networks  and  provision  for  interface  status,  as 
shown  in  the  example  of  Figure  7.  A  nondestruct  memory  would  permit  immediate  post- flight  determina¬ 
tion  of  failure  status  without  the  necessity  of  rerunning  extensive  aircraft  ground  test;  thus,  providing 
for  improved  weapon  system  turnaround  time.  Furthermore,  inflight  recording  of  fault  data  would  allow 
analysis  of  transient  type  conditiona  that  may  not  be  apparent  during  post-flight  maintenance. 


FIGURE  6.  ORGANIZATIONAL  LEVEL  TESTING 


FIGURE  7.  DYNAMIC  PERFORMANCE  MONITOR  SRU/CHIP  LEVEL 


In  the  consideration  of  sdvsnced  svionic  designs  which  allow  for  highly  fault-tolerant  architectures, 
s  standsrd  VHSIC  processor  msy  be  utilised  in  s  building  block  fashion  to  permit  sutomatic  reconfigu¬ 
ration  of  s  failed  microprocessor  component.  This  esn  be  sccomplished  by  allowing  the  stseked  processors 
to  perform  in  s  task  queue  priority  scheme,  whereby  the  processor  next  in  line  can  be  assigned  to  per¬ 
form  the  next  function  in  line.  Therefore,  if  any  processor  should  fail  in  the  queue,  the  next  processor 
in  line  would  assume  the  functional  processing  role.  This  would  provide  s  completely  transparent 


fault-tolerant  system  with  no  apparent  reduction  in  mission  performance.  The  determination  and 
partitioning  of  the  quantitative  number  of  operational  and  spare  processors  required  would  be  established 
by  the  criticality  of  specific  mission  modes  and  acceptable  reliability  levels.  The  memory  of  the  respective 
processor  elements  couiu  a,so  oe  ireaxea  as  nonaeaicatea  elements  ana  appnea  to  tne  same  reaunaancy 
management  scheme.  Standard  processing  elements  would  be  moved  as  far  out  into  the  subsystem  func¬ 
tions  as  possible  to  achieve  as  high  a  commonality  factor  as  possible.  Only  those  elements  or  functions  of 
tiit.  aubsydlefti  requiring  syeiidl  tiltuitl oulintti'b  design  iitrtd  Ot  iii,*que.  Figure  b  pi  Vldes  jXist  iUv.ii  an 
architecture  which  could  easily  accommodate  the  next  generation  fighter  multi-mission  functions. 
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FIGURE  8.  ADVANCED  ARCHITECTURE  (FAULT  TOLERANT) 


VI.  STANDARD  BUILDING  BLOCKS 


At  the  outset  of  a  new  system  design,  testability  standards  and  guidelines  should  be  established  to 
influence  the  end  product  toward  realizing  the  desirable  effect  on  availability  and  maintainability. 
However,  many  new  systems  are  partial  derivatives  of  existing  designs  or  utilize  'off-the-shelf  electronics 
and  are  highly  influenced  by  the  test  philosophy  underlying  that  predecessor  design.  Such  mixed  sys¬ 
tems  create  complex  integration  problems,  and  testability  designs  are  generally  compromised.  Further¬ 
more,  test  equipment  compatibility  is  seriously  affected,  and  the  need  for  added  test  capability  and 
interfacing  devices  is  considerably  expanded. 

To  reduce  the  diversity  of  avionic  designs,  the  author  proposes  that  a  standard  building  block 
approach  be  adhered  to  by  all  subcontractors  providing  new  electronic  systems,  subsystems  and 
component  designs.  Equipment  specifications  must  stipulate  the  design  requirements  for  both  functional 
and  testability  requirements  for  the  unit  under  test  (UUT). 

The  standards  employed  currently  at  Northrop  include,  as  a  minimum,  the  following: 

1.  MIL-STD-1750A  Computer  Architecture 

2.  MIL-STD-1589B  JOVIAL  J73B  Language 

3.  MIL-STD-1553B  Multiplex  Bus  Interface 

4.  MIL-STD-52779  Software  Quality  Control 

5.  AFR  800-14  Acquisition  Management 

6.  MIL-STD-483  Software  Configuration  Management  Practices 

7.  MIL-STD-490  Specification  Practices 

A  complementary  set  of  company  standards  such  as  a  Software  Development  and  Management  Plan 
and  a  System  Engineering  Management  Plan  (SF.MP)  also  serve  to  previde  engineering  design  direction  and 
control. 
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A  system  design  will  make  use  of  these  standards  in  a  building  block  fashion,  such  that  functions 
can  be  easily  added  or  deleted  either  from  a  software,  hardware,  or  interface  design  standpoint. 

The  areas  of  concern  relating  to  the  standard  building  block  approach  must,  however,  also  include 
consideration  of  the  following  factors: 

1.  Maturity  of  the  building  blocks 

2.  Universal  application  to  systems  and  subsystems 

3.  Common  interface  boundaries  (I/O  conversions,  protocol,  software,  physical  and  electrical 
compatibility,  testability,  etc.) 

4.  Distribution  of  functional  work  loads 

5.  Throughput  and  timing  relationships 

6.  Timeliness  and  cost  for  implementation  of  standards 

7.  Configuration  control 

8 .  Obsolescence 

The  application  of  VHS1C  designs  to  future  avionics  (e.g..  Radar,  CNI,  Fire  Control;  and  related 
fault-tolerant  designs  will  also  play  a  major  role  in  standards  of  the  future. 


Vll.  AVIONICS  OPERATIONAL  READINESS  CONTROL 


A  system  management  process  to  provide  for  timely  integration  of  Operational  Readiness  concepts 
into  the  system  design  is  important  to  successful  implementation  and  deployment  of  the  weapon  system. 
The  key  milestones  and  events  of  the  testability  design  process  are  influenced  by  the  same  events  that 
influence  the  operational  design.  Therefore,  management  controls  which  include  development  standards, 
design  reviews,  documentation  control,  baseline  management,  hardware  and  software  configuration  man¬ 
agement  and  the  like  must  be  imposed  equally  on  the  Operational  Readiness  design  requirements. 

Figure  9  provides  a  program  development  flow  which  identifies  the  critical  control  elements,  the 
most  critical  of  which  are  the  mission/ readiness  requirements  and  the  testability  design  standards/ 
guidelines.  These  requirements  must  be  established  and  approved  early  in  the  definition  phase  and  mon¬ 
itored  throughout  the  development,  test  and  verification  phases. 

Critical  design  reviews  will  include  an  in-depth  testability  design  compliance  verification  which  will 
include: 

1.  Circuit  Design  Review  (Schematic  Level) 

2.  Equipment  Test  Verification 

3.  Operational  System  Test  Compatibility 

4.  Maintenance  Support  Review 

5.  Ground  Support  Test  Compatibility 

All  of  these  reviews  will  be  conducted  in  accordance  with  established  standards  and  guidelines.  The 
acceptance  criteria  will  have  to  be  specified  at  each  level  of  evaluation  to  ensure  total  system  compliance 
from  the  bottom  up.  These  acceptance  criteria  must  be  weighted  on  the  basis  of  their  impact  on  the 
weapon  system  (availability,  mission  reliability,  and  testability,  as  well  as  life-cycle  cost)  or  objectives. 
Historically,  this  has  not  been  an  easy  task  unless  top-down  systems  management  has  been  strictly  im¬ 
posed.  To  do  this,  the  weapon  systems  manager  must  cross  all  lines  of  discipline  and  enforce  strict 
compliance  and  proper  performance  tracking  techniques.  Essential  to  the  success  of  this  top-down  man¬ 
agement  approach  is  a  timely  integration  of  the  OR  requirements  with  those  of  the  operational  development 
events. 


VIII.  CONCLUSION 


(  iC>  «)  J 


—i>  Achievement  of  Operational  Readiness  ^requires  an  interaction  with  the  functional  design  and  must  be 
built  into  the  system  and  controlled  from  the  top  down.  The  payoff  is  obtained  in  terms  of  enhanced 
mission  success,  improved  availability/ reliability,  and  reductions  in  maintenance  and  life  cycle  costs. 


Testability  in  microprocessors  must  start  at  the  level  of  the  chip  design.  Many  techniques  such  as 
nodal  summing  points,  redundancy  switching  and  dynamic  macrotest  software  are  known  today  and  can  be 
easily  incorporated  at  the  outset  of  the  processor  design,  by  utilising' automated  design  aids. 

(ul  '.  *>  J  ” 

Cost  reduction  goals  can  be  realised  with  the  elimination  of  the  intermediate  level  test  system  and  a 
reduction  in  the  cost  of  the  depot/factory  equipment.  Life  cycle  costs  can  be  drastically  lowered  by  the 
reduction  in  maintenance  training  and  support  costa, 
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FIGURE  9.  O.R.  DEFINITION  AND  CONTROL  APPROACH 

f  I 


.1  Operational  Readineaa  improvements  will  be  made  possible  by  several  new  advances  in  technology. 
The^new  electronic  components  will  permit  the  inclusion  of  advanced  testability  concepts  into  airborne 
aviomca.  Advances  in  software  and  design  of  new  distributed. system  architectures  will  provide  for  a 
universal  set  of  testing  standards.  Achievement  of ^th»- Operational  Readiness  concepts  will  be  obtained 
through  integration  and  control  of  each  of  its  related  elements,  thus  providing  a  marked  ncrease  in 
weapon  systems  effectiveness. 

AThe  deployment  of  weapon  systems  which  have  been  designed  to  comply  with  operational  readiness 
requirements  hold  -tf  significant  promise  of  improved  availability  while  reducing  life  cycle  cost  and 
manpower  requirements.jt,Comprehensivc  management  and  technical  training  efforts  are,  however,  required 
to  take  advantage  of  tlia  potential.  Guidelines  and  standards,  such  aa  those  proposed  under  the  tri¬ 
service  Joint  Logistics  Command  (JLC)  program,  will  serve  to  accomplish  these  operational  and  support 
goals. 


» 
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DISCUSSION 

M.Burford,  UK 

A  high  degree  of  standardization  is  now  possible  through  the  use  of  the  MIL  Bus,  but  will  a  standard  interface  really 
be  plastic  enough  to  cope  with  the  fault  tolerance  requirements  of  the  various  terminals  of  the  bus?  Perhaps  one 
should  really  talk  of  modularized  interface  elements  as  opposed  to  standardized  units.  T  he  required  interface 
could  be  constricted  by  defining  a  certain  mix  of  the  modules  with  the  appropriate  interleaving  software,  in  this 
case  then  perhaps  these  modules  could  form  a  library  of  standardized  elements. 

Author’s  Reply 

A  standard  interface,  be  it  a  single  VHSIC  or  several  elements,  can  be  plastic  enough  to  satisfy  the  fault  tolf  ranee 
requirements  if  properly  designed  up  front  to  do  so.  Operational  monitoring  and  wrap-around  testing  augmented 
with  interleaving  operational/test  software.  The  goal  is  not  to  stop  with  this  interface  but  also  standardize  on  the 
‘UusiyuU'ia.  laugutg.  Iltun  wiu-his,  ‘luc  tufur  I  fistic  .vsti.. 
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AVIONICS  CONCEPT  EVALUATION  AT  THE  FORCE  LEVEL 


Miriam  Cartwright  and  Terry  Haven 
Naval  Weapons  Center 
China  Lake,  California  93555 
U.S.A. 


SUMMARY 

iThe  development  of  new  avionics  systems  should  be  guided  and  supported  bv  force  level  analysis.  Evaluation  at  the 
force  level  is  necessary  in  order  to  assure  that  a  concept,  as  it  is  conceived  and  developed,  will  indeed  provide  a  significant 
increase  in  capability  when  the  resulting  weapon  system  is  used  in  an  operational  environment. 

The  Weapons  and  Tactics  Analysis  Center  (WEPTAC)  at  the  Naval  Weapons  Center  is  a  war-gaming  facility  for  doing 
force  level  analysis.  It  is  used  to  evaluate  weapon  systems  and  tactics  as  they  would  be  employed  in  realistic  scenarios 
involving  opposing  forces.  It  provides  a  valuable  tool,  therefore,  for  the  evaluation  of  avionics  concepts. 

This  paper  discusses  the  importance  of  force  level  analysis  in  avionics  system  development,  describes  the  WEPTAC 
facility,  and  gives  an  example  of  the  use  of  WEPTAC  to  evaluate  an  avionics  concept,  t. 


INTRODUCTION 

Force  level  analysis  is  the  evaluation  of  weapon  systems  in  the  context  of  important  scenarios  that  involve  many  inter¬ 
acting  friendly  and  enemy  weapon  systems,  all  employed  with  realistic  tactics.  In  other  words,  it  is  evaluation  of  weapon 
systems  in  the  complexity  of  operational  environments. 

Force  level  analysis  is  important  from  the  start  to  the  finish  of  the  development  of  an  avionics  concept.  A  new  con¬ 
cept  should  be  introduced  in  response  to  operational  needs,  which  may  well  be  discovered  by  force  level  analysis.  During 
the  process  of  concept  definition  and  refinement,  force  level  analysis  is  needed  to  evaluate  the  proposed  system’s  contribu¬ 
tion  to  weapon  system  effectiveness  in  the  operational  environment.  Based  on  the  results  of  these  evaluations,  the  concept 
may  be  redefined,  radically  changed,  or  dropped. 

It  is  important  that  today’s  scarce  funds  for  new  concept  design  and  development,  and  also  for  technology  base  research, 
be  allocated  only  to  projects  that  may  appreciably  improve  overall  weapon  system  capability  in  future  scenarios.  Force  level 
analysis  of  new  concepts  that  exploit  promising  new  technologies  can  provide  the  planner  an  important  tool  for  evaluating 
both  the  concepts  and  the  technologies. 

The  capability  to  do  force  level  analysis  is  increasing  with  the  rapid  advances  in  computer  hardware  and  software. 
Given  its  importance,  force  level  analysis  should  be  done  formally  as  part  of  the  synthesis  of  new  avionics  suites. 

The  Avionics  Division  at  the  Naval  Weapons  Center  is  developing  a  method  for  avionics  suite  synthesis.  The  method 
consists  of  an  ordered  set  of  computer  models  that  are  linked  together  to  predict  the  performance,  and  evaluate  the  effec¬ 
tiveness,  of  a  new  avionics  concept  in  the  successive  stages  of  synthesis  from  components  to  weapon  system.  The  purpose  of 
the  method  is  to  provide  a  systematic,  flexible  evaluation  process  that  will  be  used  to  guide  the  development  of  conceptual 
avionics  suites.  The  capability  to  do  concept  evaluation  at  the  very  early  stages  of  concept  development  will  also  help 
generate  a  technology  base  that  is  driven  by  requirements. 

Figure  1  shows  how  force  level  analysis  fits  into  an  overall  method  for  avionics  suite  synthesis.  An  operational  need, 
perhaps  revealed  by  force  level  analysis,  results  in  a  new  avionics  concept.  As  a  result  of  modeling  at  the  component  and 
weapon  system  levels,  values  for  performance  parameters-such  as  navigation  accuracy,  probability  of  detection,  probability  of 
kill,  probability  of  survival,  and  reliability -are  obtained.  Costs  are  also  modeled  and  judgments  are  made  about  the  tech¬ 
nological  risks  associated  with  the  new  concept.  The  performance  parameters  are  inputs  into  a  force  level  analysis  that 
evaluates  operational  effectiveness  in  terms  such  as  the  numbers  of  targets  killed  and  the  numbers  of  friendly  aircraft  lost. 
The  results  of  the  force  level  analysis  and  the  cost  and  risk  information  are  then  combined  in  an  overall  evaluation  of  the 
avionics  concept  as  it  would  be  synthesized  into  a  weapon  system,  and  the  advantages  and  disadvantages  of  the  concept  are 
summarized,  leading  to  recommendations  for,  or  against,  development. 

The  process  as  pictured  in  Figure  1  is  simplified.  In  a  typical  case,  there  wili  be  many  loops  back  to  the  beginning  to 
redefine  the  concept. 


WEPTAC 

The  synthesis  method  being  developed  at  the  Naval  Weapons  Center  uses  the  WEPTAC  war-gaming  facility  as  the  tool 
for  force  level  analysis.  Each  wsrgame  involves  three  teams  of  players:  a  friend'y  “blue”  team,  an  enemy  "red"  team,  and 
an  umpire.  At  present,  there  can  be  a  total  of  8  players  divided  among  the  teams.  A  typical  arrangement  of  the  players  in 
the  facility  is  shown  in  Figure  2. 

The  players  control  up  to  200  units,  a  unit  being  a  platform  or  missile.  Each  unit  can  be  fitted  with  up  to  30  weapon 
and  sensor  i/pes.  The  central  computer  that  provides  this  capability  is  a  16-bit,  Hewlett-Packard  system  IOOC  minicomputet. 
Plans  for  the  near  future  include  a  32-bit  minicomputer  and  the  capability  for  1 2  players  controlling  up  to  400  units. 


AVIONICS  COMPONENTS 
AND  WEAPON  SYSTEMS 


FORCE  LEVEL 


OVERALL 

EVALUATION 


NEW 

CONCEPT 


FIGURE  1 .  Force  Level  Analysis  and  Avionics  Suite  Synthesis 


Each  player  has  available  several  pieces  of  equipment  (Figure  3).  There  is  a  terminal  on  which  an  operator,  assigned  to 
the  player,  communicates  his  decisions  to  the  computer.  There  is  a  graphics  display  screen  on  which  is  mapped  the  location 
and  course  of  all  units  that  the  player  controls  or  has  information  about.  There  is  a  console  that  is  used  to  display,  in 
tabular  form,  the  status  of  any  platform  under  the  player's  control  and  the  status  of  its  sensors  and  weapons;  it  also 
displays  the  information  the  sensors  have  obtained  about  enemy  units.  Also,  there  is  a  printer  that  produces  a  record  of  all 
events  in  the  game  that  the  player  would,  in  real  life,  know  about.  Finally,  for  later  reference  and  analysis,  at  any  time  in 
the  game  a  player  can  ask  the  umpire  to  make  a  hard  copy  of  the  scene  displayed  on  the  umpire’s  graphics  display,  which 
shows  the  locations  of  all  the  units. 


The  use  of  WEPTAC  starts  with  the  definition  of  an  appropriate  scenario.  This  can  be  either  a  war-at-sea  or  a  force 
projection  scenario,  although  the  WEPTAC  projection  capability  is  limited  since  terrain  is  not  at  present  modeled.  Given  the 
initial  friendly  and  enemy  platform  positions,  the  players  make  decisions  to  maneuver  their  platforms,  manage  their  sensors, 
and  fire  their  weapons. 

As  the  war  game  proceeds,  the  results  of  the  various  interactions  are  calculated  by  the  computer  using  algorithms  that  model 


•  Detection  by  radar,  sonar,  and  other  sensors 

•  Noise  and  deception  jamming 

•  Weapon  guidance 

•  Identification  and  classification  of  targets 
Platform  courses,  speeds,  and  intercepts  are  calculated  i 


•  Communications  between  platforms 

•  Logistics 

•  Refueling 

•  Target  damage. 

three-dimensional  geometry. 


FIGURE  2.  Layout  of  WEPTAC  Player  Stations. 


At  the  end  of  the  game,  event  summaries  are  printed  out  in  various  formats  by  the  computer,  providing  much  useiui 
data  in  addition  to  the  force  level  measures  of  effectiveness  such  as  target  damage  and  number  of  survivors.  Less  tangible 
products  are  the  insights  that  arise  from  modeling  the  use  of  a  new  weapon  system  concept  in  an  operational  setting. 
These  are  as  important  as  the  quantitative  results. 

WEPTAC  realistically  models  the  process  of  operators  making  quick  decisions  based  on  partial  information.  It  is  especially 
appropriate,  therefore,  for  the  evaluation  of  avionics  capabilities  involving  information  such  as  detection,  jamming,  communi¬ 
cations,  and  identification. 

Runs  on  WEPTAC  can  be  played  either  in  a  war-game  mode,  with  the  players  making  interactive  decisions  as  described 
above,  or  in  a  noninteractive  mode.  In  a  noninteractive  mode,  tactics  are  decided  on  beforehand,  engagements  are  treated 
automatically,  and  many  runs  are  made  to  generate  statistics. 


FIGURE  3.  Player  Equipment. 


EXAMPLE  OF  CONCEPT  EVALUATION  USING  WEPTAC 

Listed  below  are  some  typical  questions  related  to  avionics  that  could  be  studied  using  WEPTAC  or  some  other  force 
level  analysis  model. 

•  How  much  additional  detection  range  would  be  useful  given  today's  weapon  systems? 

•  For  a  new  sensor  type,  what  is  acceptable  resolution  and  accuracy? 

•  How  do  tactics  affect  the  requirement  for  jam-resistant  communications? 

•  Should  ship  identification  avionics  be  in  the  weapon,  the  delivery  aircraft,  or  another  aircraft? 

•  How  useful  would  it  be  to  extend  the  range  at  which  high-value  ships  can  be  identified? 

The  following  paragraphs  describe  how  WEPTAC  might  be  used  to  .id dress  the  last  question,  and  thereby  evaluate  ? 
ship-identification  concept. 

Consider  a  conceptual  ship  identification  system  proposed  for  attack  aircraft.  It  will  provide  a  90%  probability  of 
detection  of  a  high-value  ship  at  a  distance  of  X  nautical  miles,  X  being  larger  than  the  identification  range  obtainable 
currently  and  matching  the  range  of  a  new  air-to-surface  missile.  The  time  required  io  do  the  identification  is  T  seconds. 
WEPTAC  is  to  be  used  to  evaluate  the  effectiveness  of  this  new  concept  in  killing  the  high-value  ships  in  an  enemy  task 
force. 

First  one  needs  to  choose  an  appropriate  scenario.  In  this  example  the  enemy  task  force  has  nine  ships,  three  of  these 
being  of  high-value  as  shown  in  Figure  4.  The  initial  information  state  for  the  attacking  aircraft  needs  to  be  specified.  In 
this  example,  as  the  attack  aircraft  approach  the  task  force  outside  of  their  detection  range,  it  is  assumed  that  they  know 
only  that  the  target  is  a  nine-ship  force. 

Initial  tactics  for  the  attacking  aircraft  need  to  be  decided  on.  A  coordinated  two-pronged  attack  is  shown  in  Figure  4, 
each  prong  containing  four  aircraft  that  launch  the  standoff  air-to-surface  missiles. 

Figure  5  shows  profiles  of  the  missile  launching  tactics  used  in  the  baseline  case  and  in  the  case  where  the  new  ship 
identification  system  is  used.  In  both  cases,  the  attack  aircraft  fly  in  under  the  task  force's  radar  horizon  and  pop  up  to 
detect  it  and  launch  their  missiles.  Using  the  new  avionics  system,  the  attacking  aircraft  can  also  identify  the  high-value 
ships  in  the  task  force.  However,  the  time  required  up  in  the  enemy  surface-to-air  missile  envelope  is  longer  in  order  to 
accomplish  the  identification. 


Operational  decisions  made  by  the  players  are  important.  For  example,  a  factor  tha;.  would  influence  tne  etiecu*enc» 
of  this  new  concept  would  be  the  time  at  which  an  attack  aircraft  fires  its  missiles.  How  many  ships  will  have  been  detected, 
!k>w  litany  ioertftnt,  MUt  (.anti*  iMwr.’  rCgan/l  *kx**  a  u  dMh  t»  launched  after  five  sh*s  have 

been  seen,  one  of  which  has  been  identified  as  high-value. 


FIGURE  6.  Information  State  at  Missile  Launch. 


An  evaluation  of  this  ship-identification  concept  at  WEPTAC  would  involve  several  interactive  runs.  (It  would  be  best  if 
attack  pilots  were  used  as  the  players  controlling  the  attack  aircraft  and  making  the  decisions  on  tactics  and  missile  launch 
times.)  It  might  be  that  after  the  interactive  runs,  noninteractive  runs  would  be  made  starting  from  missile  launch  in  order 
to  get  good  statistics  on  ship  kills  and  aircraft  losses. 

One  kind  of  data  one  could  obtain  from  a  WEPTAC  evaluation  of  the  new  concept  is  shown  in  Figure  7.  (The  num¬ 
bers  shown  are  hypothetical  and  not  from  any  actual  WEPTAC  runs.)  The  shad"'!  bars  show  the  results,  averaged  over  the 
appropriate  runs,  of  the  task  force  attack  when  the  aircraft  have  the  new  iden':  Nation  capability.  The  clear  bars  are  for 
the  baseline  case.  Kills  of  high-value  and  other  ships  are  shown,  as  well  as  losses  for  the  attacking  aircraft. 

If  the  data  in  Figure  7  were  real  data,  the  new  avionics  would  indeed  be  effective  in  increasing  the  number  of  high- 
rah.  flirt  *““>  TnlS  is  at  sum  C  'St,  iA  Vrevct.  in.  limiil'CT  1  jin.fl.  i  Ssct  ii.ticaSvs.  i_n.v  w,  u.c  ,1 .1  a.  i,  n  A  at  u.vx 
results  and  conclude  that  it  was  a  good  trade:  an  average  gain  of  about  one  and  a  half  high-value  ships  for  an  average  loss 
of  about  two  aircraft. 

A  closer  look  at  the  data  from  the  WEPTAC  games  might  reveal  more  information.  By  examining  the  records  of  the 
games,  it  might  become  clear  that  there  was  considerable  variation,  depending  on  the  player,  in  the  length  of  time  spent  up 
in  the  enemy  surface-to-air  missile  (SAM)  envelope  detecting  and  identifying  the  task  force  ships.  One  could  then  make 
mvxrf  rum.  with  various  pu;-w  tiau  Ottiiii,  apAcfcfe  iiv  u*4-tf f  tatwk&t  ^aiuiug  at&unxtion  atd  upi r  L  oaaag 
SAMs. 
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Figure  8  compares  the  results  for  a  particular  pop-up  time,  Tp,  and  one  that  is  three  times  as  long.  The  clear  bars  are 
for  Tp,  the  shaded  bars  for  3 Tp.  The  baseline  results,  without  the  new  capability,  are  shown  as  dashed  lines. 

If  the  results  are  as  shown,  staying  up  in  the  ships’  SAM  envelope  for  the  smaller  length  of  time  still  yields  very 
nearly  as  many  high-value  ship  kills  as  are  obtained  from  staying  up  for  the  longer  time  to  gain  more  information.  And 
now,  the  aircraft  losses  are  way  clown.  If  the  new  avionics  were  installed  in  attack  aircraft,  it  would  be  important  to  have 
some  doctrine  for  the  total  amount  of  time  spent  on  the  identification  process. 

The  evaluation  of  the  new  avionics  would  then  need  to  look  at  different  tactics,  different  management  of  the  enemy 
task  force  assets,  and  different  task  force  composition  and  orientation.  It  would  also  be  useful  to  vary  the  time,  T,  required 
for  identification  to  see  how  important  it  is  to  try  to  make  it  smaller. 
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FIGURE  8.  Effects  of  Pop-Up  Time. 
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From  all  this,  one  would  obtain  much  data  and  many  insights.  It  has  been  mentioned  before  that  the  insights  derived 
from  force  level  analysis  are  frequently  as  important  as  the  quantitative  data.  Insights  (again  hypothetical)  that  might  be 
derived  in  the  evaluation  of  new  ship-identification  avionics  are: 

•  The  new  capability  would  be  used  only  if  detection-to-identification  time  could  be  held  below  some  maximum 
value. 

•  Attack  pilots  tend  to  fire' when  the  first  high-value  ship  is  identified 

•  The  improvement  in  high-value  ship  kills  is  not  very  dependent  on  enemy  resource  management  decisions. 

WEPTAC  would  thus  produce  data  and  insights  that  could  be  used  to  evaluate  the  new  ship-identification  avionics  con¬ 
cept.  It  might  really  be  good,  or  need  some  additional  work.  It  might  tum  out  to  be  useful  only  in  special  situations.  Or 
it  might  clearly  not  be  worth  developing. 


CONCLUSION 

Force  level  analysis  plays  an  important  role  in  avionics  design.  It  can  be  used  to  evaluate  existing  systems,  develop 
avionics  requirements,  evaluate  conceptual  systems,  direct  research  and  development  efforts  to  systems  that  can  produce  large 
increases  in  capability,  and  focus  technology  base  development  towards  those  areas  that  are  most  likely  to  increase  actual 
operational  capability. 

There  are  several  advantages  to  using  a  facility  like  WEPTAC  to  do  force  level  analysis  of  avionics  concepts.  It  offers  a 
ready-made  way  to  integrate  many  systems  and  functions.  It  provides  an  excellent  forum  for  operators  and  analysts  to 
exchange  ideas,  experience,  and  data.  Seeing  the  results  on  a  graphics  display  in  real  time  is  a  very  effective  way  of  absorb¬ 
ing  information  about  a  concept’s  effectiveness.  Finally,  it  provides  the  closest  approximation  available  to  an  actual  opera¬ 
tional  environment  for  the  evaluation  of  conceptual  weapon  systems. 
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M.Burford,  UK 

The  definition  of  the  attributes  of  the  baseline  element  in  a  comparative  evaluation  of  changes  in  system  design  at 
force  level  would  appear  to  play  a  dominant  role.  In  the  past,  the  driving  motivation  has  always  been  to  produce  a 
system  superior  in  performance  to  that  held  by  the  “enemy”  or  presumed  “enemy”.  However,  in  future  the 
motivation  may  be  to  replace  an  already  superior  system  on  an  inservice  grounds.  How  are  the  attributes  of  the 
baseline  selected  or  identified  and  are  there  any  plans  to  capture  the  results  from  a  study  in  a  form  such  as  a  data 
base  so  that  the  impact  of  the  analysis  may  provide  inputs  in  future  designs? 

Author’s  Reply 

The  baseline  is  selected  by  the  user  of  WEPT  AC  or  some  other  force  level  analysis  model,  so  that  it  is  appropriate  for 
the  specific  decisions  that  his  avionics  is  intended  to  illuminate.  The  results  of  each  analysis,  as  well  as  a  summary  of 
the  scenario  and  the  important  assumptions,  are  kept  for  future  reference. 
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SUMMARY 

'"^The  increasing  cost  and  complexity  of  modem  fast- jet  aircraft,  coupled  with  the  long  development 
period  which  takes  place  while  technology  ie  changing  rapidly,  make  it  necessary  to  consider  a  new  approach 
to  system  design.  Such  an  approach  should  he  based  on  a  structured  top-down  procedure,  in  which  the  rather 
general  requirement  can  be  changed  into  a  detailed  documented  design  in  a  controlled  manner. 


One  important  aspect  of  design  ie  cost,  and  in  particular  cost-effectiveneee  and  life-cycle  cost. 

At  least  some  of  the  design  aims  can  be  based  on  cost-effectiveness  reasoning,  and  it  is  necessary  to  have 
an  appreciation  of  the  background  to  this.  Reliability-dependent  maintenance  coets  can  amount  to  much 
more  than  the  original  purchase  price,  and  hence  it  ie  essential  to  be  aware  of  the  possible  cost-drivers, 
and  include  maintenance  aspects  in  the  design  approach  from  the  beginning. 

This  paper  describes  eome  of  the  work  carried  out  at  RAE  on  theee  aspects. 

1  INTRODUCTION 


The  interval  between  feasibility  studies  and  the  in-service  date  for  offensive-support  aircraft  is 
several  years.  Increasingly  rapid  advances  in  electronics  require  that  a  new  approach  must  be  adopted  in 
future  system  design  to  avoid  aircraft  entering  service  with  unnecessarily  out  of  date  technology.  It  is 
therefore  necessary  to  start  the  feasibility  studies  by  undertaking  a  'functional  design1,  which  is  kept 
as  abstract  as  possible,  and  to  delay  producing  a  detailed  'technical  implementation'  to  as  late  ae 
reasonable  in  the  project.  The  functional  approach  has  to  achieve  a  solution  which  satisfies  agreed 
design  aims  for  safety  and  for  mission  failure.  In  addition,  life-cycle  coste  (LCC)  must  be  minimised, 
and  a  successful  attempt  to  do  thie  can  only  be  mounted  in  the  early  stages  of  design. 

The  paper  describes  work  concerned  with  this  approach,  and  covers  three  particular  areas  ae  follows: 

(a)  the  necessity  for,  and  the  approach  to,  'functional  design', 

(b)  proposals  for  design  requirements  for  safety  and  for  mission  failure,  and  practical  difficulties 
in  applying  such  aims, 

(c)  the  contribution  of  reliability-dependent  maintenance  costs  to  LCCe.  The  results  cf  a  quantitative 
analysis  of  the  various  facets  of  the  maintenance  burden  with  current  avionics  are  presented,  and 
suggestions  made  for  improvements  with  future  designs. 

2  SYSTEM  ARCHiroCTURE 

For  any  avionic  system  four  architeoturee  can  be  defined  which  represent  the  system  in  a  top-down, 
structured  manner.  They  are: 

(a)  The  Functional  Architecture!  which  defines  the  functions  which  the  system  must  perform  and  the  ways 
in  which  they  inter-relate.  Supporting  information  outlining  safety  criteria,  mission  failure  rates 
and  guidelines  for  minimum  life-cycle  cost  also  forms  part  of  this  architecture.  The  Functional 
Architecture  thus  totally  represents  the  requirement. 

(b)  The  Conceptual  Architecture;  which  represents  the  first  level  at  which  an  attempt  to  mechanise  the 
system  is  made.  This  mechanisation  ie  not  performed  in  terms  of  hardware  and  software  but,  rather 
in  terms  of  more  abstract  concepts  such  ae  the  data  flows  and  algorithms  required  to  support  the 
syetem  functions. 

(c)  The  Hardware  and  Software  architectures!  whioh  describe  the  actual  hardware  and  software  structures 
ueed  to  implement  the  Conceptual  Architecture.  Naturally,  the  implementation  will  be  determined  not 
only  by  the  functions  to  be  performed  but  also  by  the  guidelines  for  safety  etc  contained  in  the 
Functional  Architecture. 

The  relationship  between  these  architectures  is  shown  in  Fig  1  which  also  represents  the  ideal  order 
in  whioh  they  should  be  defined  ie  the  Functional  Architecture  should  be  defined  first.  This  is  not  always 
possible  because,  in  some  projeots,  the  hardware  architecture  is  pre-deflned.  Nevertheless,  the  need  for 
the  four  architectures  still  exists  to  ensure  that  a  complete  record  of  the  project  is  available  from 
requirement  to  implementation.  It  is  only  by  produoing  theee  architectures  that  subsequent  modifications 
at  any  level  oaused,  say,  by  a  re-assesBment  of  the  threat  or  a  major  advance  in  hardware  or  eoftware 
techniques,  can  be  male  in  a  top-down,  structured  manner  and  dooumented  in  a  consistent  and  unambiguous 
way. 


The  remainder  of  this  paper  describes  the  work  being  performed  at  RAE  Famborough  towards  deter¬ 
mining  methods  of  producing  Functional  Architectures  for  future  projects.  Chapter  3  will  concentrate  on 
the  functional  description  aapeots  of  the  task  while  Chapter  4  will  desoribe  the  work  that  has  been 
performed  on  design  *im«  for  safety  etc.  Chapter  5  will  discuss  design  procedures  for  mlnlmim  life-cycle 
oo8 t.  Naturally,  for  a  particular  project,  the  rather  general  work  on  design  aims  and  life-cyole  cost 
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would  form  a  background  against  which  techniques  pertinent  to  the  aircraft  and  its  operational  scenario 
would  be  determined.  These,  and  the  functions  required  to  fulfill  the  aircraft's  mission  would  then  form 
the  Functional  Architecture  for  that  project. 

3  FUNCTIONAL  DESIGN 

3.1  The  need  for  Functional  Design 

To  date,  avionic  system  design  has  been  largely  driven  by  hardware  implementation  considerations 
although,  in  recent  years,  software  implementation  problems  have  increased  in  importance.  Possible  reasons 
for  this  hardware  dominance  are: 

(a)  Most  avionic  system  engineers  are  trained  in  hardware  related  disciplines. 

(b)  Most  major  innovations  occur  as  a  result  of  hardware  related  activities  or,  at  least,  the  reporting 
of  innovation  gives  that  impression. 

(c)  Traditionally,  aircraft  functions  have  been  identified  in  terms  of  particular  pieces  of  hardware, 
often  on  a  one  to  one  basis. 

(d)  The  belief  that  software  is  flexible  has  allowed  avionic  system  engineers  to  concentrate  heavily  on 
the  hardware  design  of  systems. 

This  hardware  driven  approach  to  avionic  system  design  is  becoming  increasingly  difficult  to  apply 
for  a  number  of  reasons.  Amongst  these  are: 

(i)  Advances  in  integrated  circuit  technology  coupled  with  the  advent  of  bussed  data  transmission  tech¬ 
niques  are  leading  to  avionic  systems  in  which  individual  pieces  of  hardware  are  no  longer  associated 
with  particular  functions.  Not  only  may  a  function  obtain  data  from  and  distribute  its  processing 
among  a  number  of  hardware  items  but  also  the  way  in  which  the  processing  is  distributed  may  vary 

as  a  result  of  aircraft  phase  of  flight  and  other,  mission  related,  activities. 

(ii)  The  long  gestation  period  of  modem  military  aircraft  leads  to  a  situation  in  which  many  technical 
advances  will  have  taken  place  before  the  aircraft  enters  service.  Such  advances  cannot  usually  be 
capitalised  upon  because  of  the  current  practice  of  defining  hardware  as  early  as  possible  in  the 
procurement  cycle. 

(iii)  The  leaving  of  software  definition  until  late  in  the  project  leads  to  the  need  for  software  retrofits 
which  often  follow  the  aircraft  into  service  and  thus  lead  to  high  software  life-cycle  cost. 

It  follows  that,  in  order  to  alleviate  problems  caused  by  the  hardware  approach  to  system  design  the 
system  requirement  must  be  divorced,  as  far  as  possible,  from  the  implementation  of  the  system.  It  is 
therefore  imperative  that  early  system  design  be  performed  in  functional  terms  only  and  that  these  functions 
should  be  as  abstract  as  possible  to  distance  themselves  from  implementation  considerations.  The  technique 
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all  the  factors  that  determine  the  avionic  system  requirement  can  be  taken  fully  into  account.  Thus,  the 
functional  design  should  commence  at  a  level  at  which  logistic  support,  strategic  operational  considerations 
and  similar  pertinent  factors  are  under  discussion.  In  fact,  the  design  should  evolve  throughout  the  Air 
Staff  Target  (AST)  production  process  and  finally  produce  a  functional  description  of  the  system  which 
becomes  a  major  part  of  the  AST  and  which  industry  can  use  as  a  starting  point  for  implementation.  It  is 
interesting  to  note  that  this  approach  is  consistent  with  the  way  in  which  technological  advances  such  as 
those  proposed  under  the  VESIC  programme  will  be  exploited  in  that,  aB  the  functions  are  decomposed  to 
their  constituent  sub  functions,  a  level  will  be  reached  at  which  certain  of  the  sub  functions  can  be 
realised  directly  in  silicon. 

The  method  chosen  for  producing  the  functional  decomposition  must  be  self  documenting  and  must  provide 
readily  understandable  feedback  to  the  system  user  so  that  the  interactive  nature  of  the  system  requirement 
definition  phase  can  be  capitalised  upon.  Furthermore,  it  must  be  easy  to  update  the  documentation  when 
changes  in  requirement  occur.  The  first  need  can  be  satisfied  by  using  a  technique  based  on  diagrams  rather 
than  prose  while  the  second  aim  can  be  met  by  the  use  of  computer  aids. 

3.2  Methods  of  Producing  the  Functional  Design 

This  section  reviews  the  work  performed  to  date  on  the  problem  of  producing  functional  designs  and 
indicates  the  extent  to  which  the  ideal  approach  to  system  design,  shown  in  Fig  1,  can  be  achieved.  It 
must  be  stressed  that  the  conclusions  presented  are  tentative,  not  only  because  of  the  early  nature  of  the 
work  but  also  because  the  field  itself  1b  very  young  and  does  not  possess  the  scientific  rigour  found  in 
the  more  traditional  engineering  disciplines. 

Moat  of  the  effort  to  date  has  been  expended  in  the  search  for  suitable  tools,  with  the  system 
analysis  area  undergoing  the  most  scrutiny.  This  area  was  chosen  because  many  design  tools  have  been 
developed  as  aids  to  the  system  analyst  for  use  during  the  process  of  transforming  the  customer  requirement 
into  software.  It  was  felt  that,  because  in  many  application  in  which  commercial  systems  are  under 
development  the  hardware  is  relatively  fixed,  the  process  of  c “fining  and  documenting  the  system  software 
is  very  similar  to  that  of  defining  and  documenting  the  system.  It  was  also  decided  that,  as  far  as  possible, 
only  mature  tools,  which  possess  computer  based  support,  should  be  used  and  it  was  likely  that  such  tools 
would  be  found  in  the  system  analysis  area. 

In  the  event  two  techniques  were  discovered  which  largely  met  the  requirements;  SALT  (Softech  Inc, 

1976)  and  SAFRA  (BAe,  1980).  Both  were  applied  to  a  complex  in-house  project  and  the  results  compared.  It 
is  not  nossible  to  present  the  results  of  the  work  in  detail  in  a  pf'oer  of  this  length  but  they  are  fullv 
documented  elsewhere  (L.T.J.  Salmon,  1981,  and  M.A.  Beeny,  1982).  The  following  general  points  arose: 


(a)  SAFR A  was  more  time  consuming  in  its  application  because  it  was  more  formal  and  rigorous  than  3A2T. 

Each  functional  level  needed  a  detailed  breakdown  before  the  next  level  could  be  safely  embarked 
upon  whereas  SADT  allowed  a  rapid  breakdown  to  occur. 

(b)  As  a  corollary  of  (i),  it  was  found  that  the  transition  between  the  Functional  Architecture  and 
Conceptual  Architectures  was  difficult  to  achieve  smoothly  in  SAKE  because  of  the  lack  of  rigour  at 
higher  levels.  Ref  (?)  shows  that  the  transition  was  made  but  the  steps  involved  were  somewhat 
subjective  and  difficult  to  justify  logically.  They  were  also,  therefore, difficult  to  document. 

(c)  SAFRA  does  not  lead  to  a  clear  delineation  between  the  various  architectures,  rather,  there  is  a 

grtulwni  pXvgrVBBiwil  BJ-V.  BVttxlappld u£  CBDdb  it  Iwbcl.  .  Bb  i  O*  .b  ,  j/-.-  1'.  ■  -b.*  ’  ■  J  ttl 

least,  it  doee  produce  a  breakdown  similar  to  that  shown  in  Fig  1. 

(d)  When  applied  to  a  complex  system  both  techniques  ere  not  viable  unless  supported  by  computer  aids 
which  allow  pictorial  documentation  to  be  produced  and  consistency  checks  to  be  performed  automati¬ 
cally.  Such  aids  do  not  replace  the  need  for  innovative  thought  on  the  part  of  the  syetem  designer 
but  they  do  remove  the  tedium  caueed  by  the  need  to  update  syetem  documentation  manually  after 
change e  have  been  made  in  system  requirement.  It  cannot  be  emphasised  too  strongly  that  without 
theee  aids  both  techniques  are  not  usable. 

(e)  Both  techniques  suffer  from  limitations  caused  by  the  English  language  itself.  It  can  be  difficult 
to  find  sufficient  unique  names  for  the  mass  of  data  types  and  processes  which  exiet  in  a  large, 
complex  syetem. 

(f)  It  ie  self  evident  that  the  syetem  analysts  employed  on  the  functioned  decomposition  of  an  aircraft 
should,  between  them,  poeeeee  a  broad  experience  of  avionic  syetem  engineering.  A  conflict  exists, 
however,  in  that  in  order  to  apply  a  functional  description  technique  to  produce  a  Functional 
Architecture,  the  aircraft  must  be  thought  of  and  described  in  terms  which  are  ae  abstract  as  poeeible, 
for  reaeons  outlined  in  para  3.1.  An  analyet  with  a  wide  experience  of  avionic  syetem  engineering 
will  tend  to  think  in  terme  of  implementation  solutions  rather  than  in  terms  of  abstract  requirements. 
The  ideal  system  analyet  will,  therefore  think  abstractly,  baaed  on  his  experience,  and  be  aware  of 
thie  danger.  Such  people  are  difficult  to  find  therefore  much  care  must  be  exercised  over  the  selection 
of  staff  for  thie  task. 

As  a  result  of  the  above  investigation  SAFRA  was  chosen  as  the  method  upon  which  future  work  will  be 
based.  It  ie  intended  to  apply  the  technique  to  the  functional  requirement  of  a  complete  aircraft  project, 
not  only  to  aeseee  SAFRA  more  fully  but  also  to  validate  the  syetem  design  philosophy  outlined  in  parae  2 
and  3.1. 

4  DESIGN  HEfflJIHEMERTS 

To  support  the  functional  design,  requirements  for  safety,  mission  effectiveness  and  vulnerability 
are  needed.  Often  in  the  past,  the  approach  to  theee  design  requirements  has  been  to  propose  that  future 
systems  Bhould  be  eay  an  order  of  magnitude  'better1  than  current  ones,  or  should  be  able  to  absorb  one, 
two,  or  whatever,  failures.  Such  proposal e  are  not  based  on  particularly  rigorous  assumptions,  but  are 
usually  baeed  on  what  the  originator  considered  practical  with  the  technology  at  the  time,  and  may  be  too 
stringent.  An  approach  baeed  on  coet-effectivenees  reasoning  ie  preferable,  although  there  are  many 
practical  difficulties  and  it  ie  not  always  possible.  Moreover,  coet-effectiveneee  reasoning  often  doee  not 
permit  a  simple  univereally  applioable  figure  to  be  proposed,  since,  by  definition,  cost  and  effectiveness 
are  dependent  on  the  detailed  design.  General  guidelines  to  determining  optimum  requirements  can,  however, 
be  given. 

4.1  Safety 

In  practice,  the  safety  requirement  ie  probably  the  most  difficult  one  to  specify  and  assess.  Although 
it  might  be  possible  to  apportion  financial  costs  to  accidents,  and  then  derive  a  safety  requirement  from 
purely  coet-effectiveneee  analysis,  a  leeB  contentious  approach  is  to  reason  that  future  aircraft  should  not 
be  leee  safe  than  current  ones. 

The  safety  requirement  can  only  be  expressed  in  terms  of  the  number  of  accidents  which  can  be  accepted. 
It  is  clearly  too  facile  to  suggest  that  we  can  tolerate  no  accidents,  since  even  if  thie  could  be  achieved, 
the  resulting  aircraft  would  probably  be  unacceptably  expensive  to  purchase  and  maintain.  On  this  basis, 
the  safety  requirement  for  future  aircraft  must  be  that  they  should  be  no  less  safe  than  the  corresponding 
class  of  current  in-service  aircraft,  with  improvements  being  made  in  areas  where  these  can  be  achieved 
without  significant  cost  or  complexity  penalties. 

Examination  of  accident  records  shows  that  in  many  cases  one  can  only  speculate  on  the  cause  of  the 
accident.  Thie,  together  with  the  very  small  eample  sizes,  produced  much  'uncertainty  in  agreeing  the 
current  accident  rate  resulting  from  equipment  failure.  However,  it  would  seem  that,  at  worst,  the  major 
acoident  rate,  due  to  equipment  failures,  for  faet-Jet  aircraft,  ie  1  in  40,000  flying  hours.  Future 
systems  Bhould  be  designed  to  be  no  worse  than  thie,  and  preferably  show  an  improvement. 

There  ie,  of  oourse,  the  additional  difficulty,  namely  that  of  proving  that  a  proposed  solution  will 
meet  the  safety  requirements.  If  the  proposed  design  ie  based  on  current  techniques,  recourse  can  be  made 
to  historical  data.  If  new  techniques  are  used,  a  failure  mode  and  effect  analysis  (JMEA)  will  be  necessary. 
The  difficulty  ie  further  increased  if  pilot  interpretation  ie  involved,  since  the  pilot  reaction  can  be 
difficult  to  quantify  or  predict,  and  ia  influenced  by  factors  such  as  workload.  The  most  important  area 
where  pilot  interpretation  ie  involved,  from  a  eafety  viewpoint,  ie  the  presentation  of  flight  information 
to  the  pilot.  Normally,  in  fast-jet  aircraft,  the  pilot  has  two  more  or  lees  independent  channels  of 
flight  Information,  namely  the  head-up  display  and  the  head-down  instruments.  It  can  be  shown  that  for 
typical  eyetems,  the  pilot  is  statistically  more  likely  to  be  placed  in  a  potentially  hazardous  situation, 
not  due  to  a  failure  of  both  ohannele,  but  by  a  non-obvious  failure  of  one  channel,  when  there  ie  no  visible 


horizon.  From  a  safety  aspect  therefore,  it  is  not  the  failure  rate  which  is  important,  but  a  sub-set  of 
this,  the  non-obvious  (or  insidious)  failure  rate.  It  is  difficult  in  practice  to  obtain  agreement  on 
which  failures  are  non-obvious  but  a  reasonable  agreement  is  possible.  It  is  very  much  more  difficult  to 
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with  pilots  (particularly  on  their  experience  of  potentially  hazardous  failure),  and  examining  failure  and 
accident  information,  the  authors  have  produced  the  following  proposal  for  failures  in  systems  which 
present  flight  information  to  the  pilot: 
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and  two  meteorological  states  (ie  horizon  visible  and  no  horizon  visible).  The  safety  proposal  for  fast-jet 
aircraft  is  that  the  pilot  should  not  be  placed  in  a  potentially  hazardous  situation  due  to  a  non-ocvious 
failure  of  the  flight  information  when  there  is  no  visible  horizon,  more  frequently  than  once  in  50,000 
one-hour  sorties. 

There  is  very  little  information  on  the  ability  of  a  pilot  to  recover  from  potentially  hazardous 
failures,  largely  because  of  the  small  sample  size  involved.  The  limited  information  acquired  by  the 
authors  from  discussions  with  pilots,  suggests  that  the  failure  rates  implied  by  the  above  proposal  are 
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one-hour  sorties.  This  is  compatible  with  the  overall  accident  requirement  of  less  than  one  major  accident 
in  40,000  hours. 

4.2  Mission  Failure 

tl-%  It.  iga  vwqeHwLKUl  lx  4  .  to*  f  ’ e  1  j«  *,rr  tc  euct—r x  *»^lj  l  , 

failures  in  a  given  item  of  equipment  result  in  say  1%  of  the  ground  attack  missions  being  'lost1,  then  the 
effectiveness  of  the  fleet  is  reduced  by  1%,  and  it  can  be  argued  that  up  to  1%  of  the  aircraft  cost  can  be 
justified  in  removing  this  source  of  mission  failure,  by  say  duplicating  that  item  of  equipment.  ThuB, 
although  no  universal  figure  can  be  proposed,  the  approach  to  deciding  whether  or  not  a  particular  design 
has  an  acceptable  mission  failure  rate  is  clear. 

Two  questions  arise.  Firstly,  when  we  speak  of  cost,  should  this  be  the  purchase  price,  the 
life-cycle  costs,  or  what?  The  costs  should,  of  course,  be  life-cycle  costs,  but  the  limited  data  which 
the  authors  have  to  hand  suggests  that  the  figure  for  the  ratio  of  the  life-cycle  coBts  (LCC)  to  purchase 
price  is  approximately  the  same  for  a  complete  aircraft  as  for  an  item  of  complex  avionics.  Thus,  at  least 
for  coupler  avionics,  preliminary  rough  assessments  can  be  made  using  purchase  price.  Secondly,  is  dupli¬ 
cation  the  best  approach,  or  should  efforts  be  made  to  improve  reliability,  or  should  a  lower  accuracy,  but 
less  expensive  standby  system  be  incorporated?  The  cost-effectiveness  analysis  of  these  options  is,  at 
least  mathematically,  trivial,  and  is  not  pursued  here.  However,  an  important  aspect  of  the  design  of 
future  aircraft,  particularly  where  off-base  operation  in  small  groups  is  envisaged,  is  the  ability  to 
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context,  depending  on  the  detailed  scenario  envisaged  a  simple  reliable  and  independent  standby  system 
might  be  more  useful  than  duplicating  items  of  main  equipment. 

4.3  Vulnerability 

Vulnerability  in  this  context  is  taken  as  being  vulnerability  to  eneay  action.  The  importance  of 
vulnerability  can  be  illustrated  very  simply.  For  a  large  fleet  of  aircraft,  taking  attrition  rates  per 
sortie  of  1%,  5 %  and  1C%,  then,  neglecting  any  limitations  in  repair  facilities,  the  average  numbers  of 
sorties  flown  per  aircraft,  before  all  are  'loaf,  are  respectively  100,  20  and  10. 

The  question  thus  arises  as  to  how  far  can  one  justify  measures  to  reduce  attrition?  It  can  be 
shown  that,  at  a  simple  level,  the  answer  is  independent  of  the  details  of  the  scenario,  other  than  a 
knowledge  of  the  damage  characteristics  of  the  threat.  If  the  attrition  rate  can  be  reduced  by  say  10%, 
ti...  ncflub,r  -f  j.rtl.d  li„r^cd-o  jj  lift,  1-  in  ti-  _bjv« ,  if  th.  -ttritljs.  rut—  Sore  i, iuc.l 

0.9%,  4.5%  and  9%,  the  average  number  of  sorties  flown  per  aircraft  rises  to  110,  22  and  11  respectively. 
Thus,  at  a  simple  level,  measures  taken  to  reduce  the  vulnerability  by  10%  are  equivalent  to  an  increase 
in  fleet  size  of  1C%.  A  basis  for  a  coat-effectiveness  analysis  is  therefore  established.  It  is,  of 
course,  necessary  to  predict  the  damage  caused  by  the  particular  type  of  missile,  shell,  etc,  but  much 
experience  has  been  built  up  over  the  yearB  in  this  area, 

5  AVIONICS  MAINTENANCE  COSTS 


It  ia  generally  agreed  that  the  reliability-dependent  maintenance  cost  for  complex  avionios,  when 
taken  over  the  life  of  the  equipment,  is  typically  much  greater  than  the  original  purchase  price  of  the 
equipment,  and  it  ia  necessary,  in  the  early  Btagea  of  equipment  design,  to  design  for  minimum  life-cycle 
costs.  There  is  much  less  agreement  on  how  we  actually  achieve  this! 

In  order  to  contribute  proposals  on  the  way  ahead,  and  to  be  able  to  assess  the  various  opinions 
expressed,  the  authors  needed  to  obtain  background  education  on  a  breakdown  of  maintenance  costs  for 
avionic  equipment  currently  in-service.  Accordingly,  12  avionic  line  replaceable  units  (LRUs)  for  a 
current  fast- jet  airoraft  were  selected,  and  the  maintenance  man-hours  expended  in  testing  and  defect 
rectification  at  the  various  servicing  levels  determined,  ttese  results  were  combined  with  the  results 
of  other  studies,  to  produce  the  cost  pie  diagram  of  Fig  2.  It  must  be  emphasised  that  there  was  a  large 
spread  in  the  values  for  individual  MTs.  The  average  values  are  presented  in  Fig  2. 

For  the  12  LRUs  selected  in  this  survey,  the  dominant  costs  are  3rd/4th  line  and  spares.  At  1st 
line  (ie  work  carried  out  at  the  aircraft),  activities  are  restricted  to  testing  ths  system,  and  replacing 
defective  LRUs:  at  2nd  line  (ie  work  carried  out  in  the  repair  bays  on  the  airfield),  rectification  is 
typically  confined  to  diagnosing  the  defect  to  module  level,  and  replacing  the  defective  module,  while  at 
jrf  sax?  4®  line  (ie  mft  milled  Jtrt  in  ittf  repair  facilities,  Jfr  Juriaetry,  respective iy) , 

defects  are  diagnosed  to  component  level.  Since  equipment  is  usually  designed  so  that  defects  to  LRU  and 
module  level  can  easily  be  diagnosed,  it  is  perhaps  not  surprising  that  3rd/4th  line  oosts  (involving 
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diagnoele  to  oomponent  level  and  replacement  of  the  defective  component)  are  relatively  large. 

Spare  LEO'S  need  to  he  held  to  supply  1st  line,  and  spare  modules  to  supply  2nd  line.  The  cost  of 
the  sparee  holding  therefore  depends  upon  the  reliability  of  the  LEO  and  the  reliability  of  the  individual 
modules,  the  oost  of  the  LRU  and  individual  modules,  and  the  length  of  time  that  the  LEO  and  modules  are 
"loet  in  the  repair  chain" . 

Assuming  that  future  avionics  will  have  a  similar  oost  pattern  to  the  12  LHOs  chosen  In  this  etudy, 
then  it  is  clear  that  a  broad  view  must  be  taken  if  life-cycle  costs  are  to  be  reduced.  There  is  little 
point  in  concentrating  on  just  one  aspect  say  improved  testability  for  1st  and  2nd  line  diagnosis  -  which 
ie  a  suggestion  frequently  proposed  -  if  this  is  likely  to  result  in  increased  costs  elsewhere.  Repair 
costs  can  only  be  minimised  by  designing  the  system  and  LRUs  such  that  the  total  repair  costs,  considered 
as  the  sum  of  the  contributions  from  each  of  the  servicing  levels,  are  minimised. 

There  is  therefore  a  need,  in  futun-  system  design,  to  consider  not  only  LEU  reliability,  but  the 
•total  cost1  of  repairing  a  defect.  The  detailed  equipment  design  must  be  such  as  to  minimise  this  total 
cost  of  repairing  a  defect.  Special  attention  should  be  given  to  the  3rd/4th  line  costs  (locating  a  defect 
to  component  level,  and  subsequent  repair).  The  cost  of  spare  holdings  of  modules  is  aleo  influenced  by 
the  detailed  design.  For  instance,  if  meet  of  the  purchase  cost  and  the  unreliability  of  an  I£U  arose  from 
a  relatively  small  number  of  modules  in  that  I£U,  the  cost  of  spare  modules  necessary  to  supply  the  2nd 
line  eervicing  would  be  greater  than  if  the  cost  and  unreliability  were  divided  equally  between  all  the 
modulee.  Thus  comparative  studies  of  alternative  detailed  designs  should  be  undertaken  by  the  manufacturer 
in  the  early  deeign  stages  to  ensure  that  the  eventual  eolution  his  minimum  LCC. 

6  CONCLUSIONS 
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but  there  is  a  need  to  test  the  practicality  of  the  approach  by  tackling  a  complete  aircraft,  and  seeking 
involvement  from  a  wider  range  of  specialists  who  have  not  had  prior  experience  of  this  design  approach. 
flJMlixl# ,  ILe  pKiU/sal,  T.r  Sp'ilgu  r-jillror  1  ec&  fer  Efcr-.lht.fftg  W ,  ^Hbuugji  111** jd  i.  V  If) 

themeelves,  need  to  be  applied  to  worked  examples  to  assess  whether  their  rather  general  approach  will 
limit  the  extent  to  which  they  are  of  value  in  practice. 
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VERS  UNE  MODULARITE  DU  LOCICIEL 


CONCUE  POUR  LES  BESOINS  DE  L' UTILISATEUR 


P.  CATEL 

ELECTRONIQUE  SERGE  DASSAULT 
55  quai  Carnot 
92214  SAINT-CLOUD 


RESUME 


Aprla  avoir  resltud  le  contexts  du  loglclel  d'un  calculateur  principal  de  systAme  avlonlque,  ce  document 
prdscnte  la  demarche  accomplia  par  ESD  pour  la  recherche  d'une  modular it*  du  loglclel  adaptSe  aux  besolns 
de  l'utlllsateur.  Cette  demarche  a 'eat  d6roul6e  en  deux  phasea  : 

-  La  premiere  concernalt  dea  applications  de  tallle  moyenne  ( jusqu'A  64  K  mote)  et  a  permls  de  d§flnlr  une 
atructure  du  loglclel  et  dea  rAglea  de  ddcoupage  du  problime. 

-  La  aeconde  eat  apparue  4  l'occaalon  du  ddmarrage  d'une  nouvelle  application,  d'un  volume  plua  Important, 
devant  *tre  la  baae  d'une  famllle  d'appllcatlona  importante. 

Une  Ctude,  manCe  conjolntement  avac  le  cpCclficateur  du  loglclel  (le  maltre  d'oauvre  du  systAme),  a  per- 
mla  dlffCrentea  amelioration*,  auaal  blen  aur  le  plan  de  la  structure  que  dea  mCthodes  et  dea  rAgles  de 
ddcoupage,  dans  la  but  d'obtenlr  une  rCcuperablllte  parfaite  d'entltCa  de  loglclel.  Elle  a 'eat  concrC- 
tlsCe  par  la  mlae  en  oeuvre  de  nouveaux  out  11s,  et  dea  extensions  de  la  Machine  Vlrtuella  du  calculateur 
utilise. 


1.  INTRODUCTION 


L' ELECTRONIQUE  SERGE  DASSAULT  (ESD)  eat  apdclallsee  dans  l'Ctude,  le  ddveloppement  et  la  fabrication 
d'Cqulpements  dlactroniques  de  polnte,  tant  dans  le  domalne  mllitalre  que  dans  le  domalne  civil. 

L'effectlf  da  l'ESD  eat  de  3200  peraonnea,  dont  1800  lngdnleurs  et  cadres.  L'lnformatlque  adrospatlale 
(calculateur*,  bua  numCrlquea,  ayatimaa  digltaux,  loglclela  de  baae  et  d'appllcatlon)  constltue  une  dea 
actlvltCs  prlnclpales  da  1 ' ELECTRONIQUE  SERGE  DASSAULT  :  20  4  25  X  du  chlffre  d'affaires  eat  realise 
dans  ce  domalne. 

Depuls  1965,  Cpoqua  4  laquelle  l'ESD  a  conqu  le  premier  calculateur  embarquC  europden  utillaant  dea 
circuits  lntCgrea,  lea  mlaallea  b*'latlquea  franqala  aont  dqulpda  de  calculateurs  universale  ESD,  pula 
ESD-SAGEM  4  la  suite  d ’accords  d»  ipdratlon  algnCa  entre  lea  deux  soclCtCs. 

En  1976,  l’accrolssemant  dea  besolns  en  aatidre  de  puissance  de  calcul  conduit  l'ESD  4  promouvolr  en 
France  da  nouvellea  tachnologlea  da  composants  et  de  circuits  pour  crCer  una  nouvella  generation  de 
calculateurs  unlversels  : 

-  1084  pour  missiles  bulistiquas, 

-  MI82  pour  aviona  MIRAGE  FI, 

-  2084  pour  aviona  MIRAGE  2000. 

Le  ayatdme  de  transmission  dea  Informations  numCriquea  4  bord  de  ces  aviona  a  lui  auaal  ttt  dCveloppd 
par  ESD  :  e'est  le  bua  numdrlque  GINA  (DIGIBUS),  normalise  depuia  aeptembre  1982  par  la  Mlnlstire  de  la 
Difenae  franqals  sous  la  reference  GAMT101. 
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L'ESD  realise  £galement  tous  les  logiciels  de  base  et,  sous  la  raalcrise  d'oeuvre  de  ses  clients,  la 
plupart  des  logiciels  d'appllcatlon  concernant  ses  propres  calculateurs  aArospatiaux.  L'introductlon  de 
la  nouvelle  generation  de  calculateurs  ESD  en  tant  que  calculateurs  principaux  des  avlons  MIRAGE  FI  et 
MIRAGE  2000  a  conslderablement  developpe  cette  activlte  loglciei. 

Les  logiciels,  dans  les  applications  avloniques,  prAsentent  des  caracterlstiques  specifiques  :  les 
aspects  les  plus  marquants  sont  la  flablllte,  et  les  contralntes  de  realisation  (concision  du  volume 
aAiiolre  et  charge  de  calcul)  qui  sont  encore  sensibles  avec  les  materiels  dlsponlbles  aujourd'hui. 

Cependant,  le  volume  sans  cesse  croissant  de  ces  logiciels  fixe  une  nouvelle  priorlte,  celle  de  pouvoir 
reutlllser  les  parties  les  plus  grandes  possibles  de  logiciels  d6jA  exlstants  pour  realiser  le  loglciei 
d'un  nouveau  systAme. 

Ce  besoln  se  fait  sentlr  non  seulement  au  niveau  de  la  realisation  proprement  dlte  du  loglciei,  mals 
aussl  -et  peut-ltre  surtout-  pour  reduire  1' effort  d'  integration  et  de  raise  au  point  (au  sol  et  au  vol) 
du  systAme  global. 

la  reponse  est  apportee  par  une  conception  modulalre  du  loglciei  developpe.  Ce  document  presente  notre 
approche  de  ce  problAme,  qui  peut  €tre  decoupee  en  deux  phases.  La  premiAre  concerne  des  logiciels 
developpes  Jusqu'en  1981,  d'une  taille  moyenne  (volume  memoire  des  calculateurs  limltAe  A  6A  K) . 

La  seconde  phase  est  liee  au  developpement  de  nouveaux  logiciels,  dont  le  volume  A  terme  sers  beaucoup 
plus  important,  ce  qui  nous  a  amenA  A  adapter  A  la  fol3  les  caracterlstiques  de  nos  calculateurs  et  nos 
methodes  de  realisation  du  loglciei. 

Avant  de  d6crlre  ces  deux  phases,  nous  allons  rsppeler  le  contexte  dans  lequel  se  sltue  le  loglciei  du 
calculateur  principal,  puls  definir  ce  qu'est  la  modularlte  d'un  loglciei. 


2.  CONTEXTE  DO  LOCICIEL  D'UN  CALCULATEUR  PRINCIPAL 


2.1.  Fonctlons  du  Calculateur  Principal  dans  un  systAme  d'armes  avionlque 


Le  systAme  de  navigation  et  d'attaque  (SNA)  d'un  avion  de  combat  moderne  peut  6tre  trAs  schAmati- 
quement  lllustrA,  dans  son  prlnclpe  general,  par  la  figure  sulvante  : 


» 


a 


Paral  lea  prlnclpaux  Squlpeaents  du  SNA,  on  distingue  : 

-  dea  capteurs  flxea  ou  aontSs  en  pod  :  centrale  1  lnertle,  centrale  hydrodynaalque, 
radar,  etc... 

-  dea  postea  de  visualisation  :  Scran  tCte  basse,  viseur  tSte  haute,  etc,,, 

-  dea  postea  de  cooaande  :  pour  la  navigation,  l'araeaent,  le  radar,  etc,,. 

-  des  circuits  d’armeaents  :  pour  boabes,  canons,  alsslles,  etc,,, 

Blen  que  toua  ces  Equlpeaeuts  coaportent  une  part  de  plus  en  plus  grande  d’Slectronique  nuaSrlque, 
c’est-l-dlre  de  processeurs  spSclallsSs  et  trAs  IntSgrSs  au  aatSriel,  les  calculs  effectuSs  y  sont 
de  nature  diffSr-nte  de  ceux  du  calculateur  principal  :  11s  sont  spSclflques  de  l'Squipeaent , 
contrlbuent  dlrecteaent  A  ses  performances  et  ne  traltent  gSnSraleaent  que  des  donnSes  locales, 

Au  contralre,  le  loglclel  du  calculateur  principal  lntervient  au  niveau  global  du  systAme  de  faqon 
reiativeaent  IndSpendante  des  caractSristlques  partlcullAres  des  Squlpeaents.  II  assure  deux  types 
de  fonctlons  : 

-  des  fonctlons  de  gestlon  centrallsSe  (Schanges  d'lnforaatlon,  surveillance  du  fonctlonnement 
d' ensemble )  : 

Le  schSaa  fait  apparaltre  le  r61e  partlculler  du  (ou  des)  bus  mnSrlque  ou  "dlglbus"  auquel  sont 
connectSs  la  plupart  des  Squlpeaents  du  systAme  d'araes,  Les  informations  SchangSes  entre  ces 
Squlpeaents  transltent  sur  cette  ll.-.ison  sous  forae  nuaSrlque  et  sulvant  un  mode  de  aultlplexage 
teaporel  A  haute  frSquence,  Les  liaisons  dlrectes  entre  Squlpeaents  sont  de  plus  en  plus  rares  ; 
11  en  subslste  encore  quelques  une a  pour  diffSrentes  raisons  (survlvance  de  techniques  analo- 
glques,  dSblt  d' informations,  sScuritS), 

La  gestlon  du  bus  nuaSrlque  est  assurSe  par  le  calculateur  principal,  Celul-cl  peut  Stre  dSdoublS 
pour  des  raisons  de  flabllltS,  en  partlculler  pour  assurer  la  gestlon  du  bus  en  cas  de  dSfail- 
lance  du  premier, 

-  des  fonctlons  opSratlonnelles  :  A  partir  des  donnSes  SlaborSes  par  les  capteurs  et  des  ordres 
lntrodults  manuelleaent  sur  les  postes  de  comaandes  par  le  pllote,  le  calculateur  principal 
effectue  un  certain  noabre  de  tralteaents  permettant  d'assurer  les  missions  opSratlonnelles  de 
1' avion  :  navigation,  attaque  Air-Sol,  attaque  Air- Air  ;  sulvant  la  mission,  certains  rSsultats 
de  calculs  sont  adressEs  A  des  Squlpeaents  comae  les  circuits  d'araement,  d'autres  informations 
sont  prEsentEes  au  pllote  sur  les  postes  de  visualisation,  Dans  quelques  cas,  une  partle  de  ces 
tralteaents  est  effectuSe  par  des  calculateurs  implant As  dans  le  radar  ou  le  viseur  par  exemple. 
La  presence  d'un  second  calculateur  principal  peraet  d'y  laplanter  un  certain  noabre  de  traite- 
ments,  augment  ant  alnsl  la  capacltE  globale  de  calcul  au  niveau  systEm*. 


2,2,  CaractSristlques  du  loglclel 


La  prSsence  d'un  calculateur  principal  dans  un  SNA  off re  un  certain  noabre  d'avantages.  Par  sa 
structure  de  calculateur  unlversel,  11  va  apporter  en  effet  une  grande  puissance  de  calcul,  male 
11  va  Sgaleaent  constltuer  l'SISaent  de  souplesse  prlvllSglS  du  SNA  :  c'est  par  des  adaptations  de 
son  loglclel  et,  dans  certains  cas  de  son  matSrlel  (au  niveau  des  coupleurs),  que  l'on  va  pouvolr 
intSgrer  dans  le  SNA  des  Squlpeaents  exlstants  sans  modification  de  ceux-cl  (partlculiArement  les 
capteurs  et  les  araements  dont  les  techniques  trAs  spSclflques  font  qu'll  est  en  gSnSral  plus 
pSnallsant  de  les  modifier,  cela  entralnant  des  mlses  au  point  souvent  longues). 


Par  allleurs,  11  va  assurer  un  rSle  primordial  dans  les  tralteaents  USs  A  la  mise  en  oeuvre  du 
SNA,  et  partlcullSreaent  les  problAaes  de  dialogue  homme-systAae .  Notaaaent,  11  assure  la  gestlon 
des  Squlpeaents  A  usage  gSnSral,  comae  les  postes  de  visualisation  et  les  postes  de  comaande,  et 
les  conflgurant  selon  les  spSclflcltSs  de  chaque  aode  dont  le  systSme  est  capable. 


Ces  2  aspects  ont  comae  consSquence  que  les  loglclels  des  calculateurs  prlnclpaux  supportent  de 
trAs  nombreuses  modifications  tout  au  long  de  leur  cycle  de  vie.  En  effet,  d'une  part  lls  doivent 
aulvre  les  Svolutlons  des  dSflnltlons  des  Squlpeaents,  d'autre  part  les  solutions  aux  problAaes 
ergonoalques  sont  souvent  longues  A  mettre  au  point,  Le  taux  courant,  sur  nos  pro jets,  est  de 
recevoir  environ  1.5  demandes  devolutions  par  jour  ouvrable,  pendant  toute  la  phase  de  dSvelop- 
peaent .  Ces  Svolutlons  permanentes  ne  favorlsent  pas,  blen  sOr,  la  standardisation  du  loglclel. 


Sur  un  autre  plan,  la  tendance  gSnSrale  est  une  sophistication  toujours  plus  grande  des  systAmes, 
due  A  dea  accrolsaeaents  de  leurs  possibllitSs  pour  la  aise  en  oeuvre  d'armeaents  de  plus  en  plus 
noabreux,  et  de  plus  en  plus  complexes.  Cela  a  en  partlculler  comae  consSquence  une  recherche  de 
l'allAgeaent  des  ttchea  du  pllote,  se  tradulsant  entre  autre  par  des  Elaborations  d' informat Ions 
toujours  plus  synthStlques,  et  Sgsleaent  l'autoaatlsation  de  certalnes  prises  de  dSclslon. 

Ces  Svolutlons  se  tradulsent  par  un  accrolsseaent  permanent  du  voluae  du  loglclel  des  calculateurs 
prlnclpaux.  II  en  rSsulte  une  Evolution  dans  sa  perception  par  les  utlllsateurs.  D'une  approche 
lnltlale  oO  la  rSaction  noraale  A  une  deaande  nouvelle  Stait  : 

-  ";a  ne  touche  que  le  loglclel,  11  n'y  a  pas  de  problSae”,  on  tend  vers  une  attitude  opposSe,  ofi 
le  loglclel  apparalt  comae  quelque  chose  de  secret,  difficile  A  aaltrlser,  en  Evolution  perma- 
nente  et  dont  le  coQt  est  de  plus  en  plus  prSoccupant. 
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Le  rgallsateur  du  logiciel  a  autant  de  difficultgs  i  expliquer  qu'une  Evolution  est  faisable, 

Sana  obligatolrement  tout  reaettre  en  cause,  qu’il  en  avait  autrefois  3  falre  coaprendre,  qu  elle 
n'gtait  pat  aussl  slapllste  que  ses  interlocuteurs  avalent  tendance  3  le  supposer. 

II  est  certain  qu’un  logiciel  est  complexe,  ne  terait-ce  que  par  le  noabre  d'inforaacions  traitges 
le  calculateur  principal  d'un  systdae  actuel  doit,  par  exeaple,  recevoir  de  I'ordre  de  900  infor- 
aations  diffgrentes,  logiques  ou  numgriques,  pour  en  ggndrer  environ  1300- 

Face  3  un  tel  probldme,  il  exlste  une  seule  solution  :  "diviser  pour  rggner"  ou  rgdulre  le  probldme 
ccaplet  en  sous-probl3aes  auffisaaaent  petits  pour  que  chacun  puisse  Stre  aaltrisg.  D'oO  la 
ngcessaire  modularitg  du  logiciel. 

Cette  modularise  va  ggalement  4tre  mise  3  profit  pour  permettre  la  rgcupgration  d'fclgments  entre  un 
logiciel  et  un  autre.  Cette  dgaarche  est  cependant  beaucoup  plus  difficile  3  faire  passer  dans  les 
faits,  car  elle  ngcessite  une  approche  cohgrente  de  la  psrt  de  toutes  les  personnes  impllquges 
dans  la  chatne,  du  pilots  au  programmeur. 

2.3.  Interlocuteurs  lmpllqugs  dans  le  dgveloppesignt  d'un  logiciel 

Le  dgveloppement  d’un  logiciel  fait  intervenir  deux  responsabilitgs  : 

-  le  Spgclflcateur  du  logiciel  est  l'avionneur,  maitre  d'oeuvre  du  systdme.  Son  r61e  est  de  conce- 
voir  le  Systdme  de  Navigation  et  d'Armements,  ce  qui  se  fait  en  deux  Stapes  : 

.  Definition  globale  du  syst8ae  :  cette  gtape  concerne  le  niveau  systdme,  et  le  projet  logiciel 
y  est  seulement  identifig.  Elle  consiste  3  : 

-  dgfinir  le  systdme  du  point  de  vue  de  ses  utilisateurs,  en  dScrivant  globalement  ses  F0NC- 
TIONS  OPERATI0NNELLES ,  ses  Interfaces  avec  1 'envlronneaent ,  ses  performances, 

-  identifier  les  SOUS-ENSEMBLES  natSriels  et  logiciels  du  syst8me  et  mettre  en  Svidence  le 
r81e  de  chacun  d'eux  dans  la  realisation  de  chaque  fonctlon  opgrationnelle . 

Cette  6tape  est  concrgtisSe  par  le  document  de  SPECIFICATIONS  GLOBALES  DU  SYSTEME. 

.  Definition  opgratlonnelle  du  logiciel  : 

La  definition  opgrationnelle  du  logiciel  ne  peut  s’effectuer  que  dans  le  cadre  d'une  DEFINITION 
DETAILLEE  DU  SYSTEME  qui  consiste  3  : 

-  dgcrire  chaque  fonction  opgrationnelle  de  faqon  complete  et  precise, 

-  rSpartir,  pour  chaque  fonction  opgrationnelle,  les  traitements  entre  les  diffgrents  sous- 
ensembles, 

-  determiner  les  interfaces  entre  les  sous-enserables. 

Les  travaux  relatifs  au  sous-ensemble  logiciel,  objet  du  projet,  constituent  la  DEFINITION 
OPERATIONNELLE  DU  LOGICIEL. 

La  psrt  incombant  au  logiciel  dans  chaque  fonction  opgrationnelle  est  appelge  CHAINE  LOGICIELLE 

Les  traitements  de  chaque  chalne  logiclelle  sont  d6crits  d'un  point  de  vue  opgrationnel  (non 
informatique)  de  la  maniSre  la  plus  complete  et  la  plus  precise  possible.  En  particulier,  tous 
les  choix  relevant  de  la  responsabilitg  demandeur  sont  explicitement  dgflnls. 

Cette  gtape  est  concrgtisge  par  le  cahier  des  charges  du  logiciel,  constitug  par  : 

-  les  SPECIFICATIONS  OPERATIONNELLES  DU  LOGICIEL, 

-  les  SPECIFICATIONS  DES  INTERFACES  DU  LOGICIEL. 

-  Le  Rgallsateur  du  logiciel  va  en  assurer  la  conception  et  la  realisation. 

Si  les  responsabilitgs  sont  nettement  marquges,  il  est  trds  profitable  aue  le  transfert  des 
t3ches  entre  demandeur  et  rgallsateur  se  fasse  plus  progressivement •  En  particulier,  le  rgall- 
sateur  va  participer  3  la  phase  de  definition  opgrationnelle  du  logiciel,  et  le.  spgciflcateur  va 
au  minimum  contrfiler  les  rgsultats  de  la  phase  de  definition  fonctionnelle  du  logiciel,  qui  est 
la  premiire  menge  sous  la  responsabilitg  du  rgallsateur. 


3.  DEFINITION  DE  LA  MODULARITY  DU  LOGICIEL 
3.1.  Definition 


Un  prodult  eat  dlt  modulalre  a  partir  du  moment  od  11  est  constitue  d'61ements  independants,  dont 
1' assemblage  conduit  3  un  tout  coherent.  Dans  le  cas  d'un  loglclel,  on  est  aaene  en  fait  &  conce- 
volr  une  structure  hlerarchisee,  dans  laquelle,  lorsqu'on  part  des  coaposants  eiementaires,  11 
exlstc  plusleurs  nlveaux  de  regroupement  successlfs. 

Le  prealer  bSneflclalre  de  la  aodularlte  est  le  rfallsateur.  Celle-cl  va,  en  effet  lul  pemettre 
de  contrfiler  le  d€veloppement  du  loglclel  et  aussl  de  tenlr  les  objectifs  de  flabillte,  chaque 
niveau  d'lntegratlon  constltuant  un  niveau  de  test. 

Le  deuxlSme  apport  de  la  aodularlte  est  la  posslblllte  de  aodlfier  un  616ment  a  l'un  quelconque  des 
nlveaux,  sans  reaettre  en  cause  les  autres,  et  done  d'apporter  une  grande  souplesse  pour  Involution 
d'un  loglclel. 

Dds  lors,  le  problSae  de  la  modularlte  du  loglclel  dolt  6tre  aborde  sur  deux  plans  : 

1)  Le  plan  structure! 

C'est  le  probl&ae  du  contenant,  autreaent  dlt,  11  convlent  de  deflnlr  ce  que  seront  les  dif- 
ferents  nlveaux  auxquels  des  eieaents  de  loglclel  seront  aanlpulables.  II  y  a  19  une  premiere 
source  de  difficult^  :  er.  effet,  tout  le  monde  salt  de  quol  on  parle  lorsque  l'on  nomme  des 
dlff£rents  elements  d'un  materiel  :  une  carte,  un  hybrlde,  cela  se  volt  et  se  touche.  L’aspect 
raccordement  (prises,  connecteurs,  pattes)  est  perqu  facllement. 

Four  le  loglclel,  par  contre,  la  situation  est  diff£rente,  pour  au  molns  2  raisons  : 

-  La  premiere  est  qu'un  loglclel  ne  se  volt  pas.  L'appr£henslon  se  fait  sur  le  papier,  dans  des 
listings  ou  dlff£rents  documents  de  description,  dont  la  langue  est  plus  ou  molns  r£barbatlve, 
rnals  rebute  en  general  tout  non  lnformatlclen. 

-  La  deuxldme  est  qu'll  n'y  a  pas  un  vocabulalre  unlversel  dfiflnissant  des  elements  de  structures 
dQment  Identifies.  Blen  sQr,  tout  le  monde  parle  de  module,  mals  quand  on  regarde  de  pr6s,  on 
s’aperqoit  vlte  que  qa  ne  recouvre  Jamals  les  mSmes  notions. 

2)  Le  plan  fonctlonnel 

C'est  le  probldme  du  contenu,  e'est-a-dire  celul  qul  conslste  S  dSflnlr  le  rble  de  chaque 
element  de  la  structure.  Le  probldme  essentlel,  lei,  est  de  faire  colncider  les  exigences  au 
niveau  de  la  realisation  du  loglclel,  116es  a  la  technique  informatique  avec  les  besolns  des 
utlllsateurs  qul  manlpulent  des  notions  qul  peuvent  Gtre  a  priori  toutes  autres. 

En  fait  les  premieres  personnes  concernees  par  la  modularlte  du  loglclel  ont  ete  les  reallsateurs 
de  celui-ci.  Leur  premier  soucl  etait  de  resoudre  les  difficultes  liees  3  la  realisation  d'un 
loglclel  avionique  :  flabillte,  testablllte,  et  €galement  les  aspects  lndustrlels  :  tenue  des 
deials,  des  coQts  de  realisation,  prevision  et  sulvl  des  charges  de  calcul  et  des  volumes  mCmolre. 

Cependant,  la  modularlte  du  loglclel  n'est  valable  que  si  les  deux  aspects  du  probia»e  sont  correc- 
tement  traltes. 


3.2.  Reutlllsatlon  d'un  loglclel 

Une  seconde  notion  generale  reste  3  pr6clser,  celle  de  "recuperation"  d'un  loglclsl  cxistar.t. 
Classlquement,  un  loglclel  est  obtenu  en  deux  €tapes,  comme  schematise  sur  la  figure  ci-dessous. 


Blnalre 

absolu 


La  premi3re  (tape  eat  la  compilation.  Elle  conslste  3  transformer  un  programme  source,  rfdigf  en 
diff "rents  langages  (LTR,  macroassembleur,  asseableur,  ...)  en  un  programme  blnalre  relogeable. 
Cette  compilation  est  rfallafe  lndfpendaaaent  sur  chacune  des  unites  flfmentalres  de  loglclel,  on 
a  done  le  mime  nombre  d'entitfs  “blnalre  relogeable"  que  d'entitfs  "source". 

La  seconde  f tape,  r falls Se  par  l'fdlteur  de  liens,  conslste  1  rfunlr  toutes  les  entitfs  nfeessaires 
(leur  llste  est  dffinie  par  des  directives  donnfes  3  l'fdlteur  de  liens)  pour  composer  un  programme 
executable.  L'fdlteur  de  liens  peut  alors  gf nf rer ,  un  blnalre  absolu,  c'est-3-dlre  un  programme 
dlrecteaent  chargeable  dans  le  calculateur. 

Le  me 11 leur  niveau  de  recuperation  est  celul  qul  conslste  3  reprendre  des  blnalres  relogeables- 
dela  ,  till-,  t  diet  1c  a'alftaOrUt  du  eotll  eV  ued  lei  a  nf  ueadali  LJ  puut  uue  e  abpllarlon.  11 
n'en  reste  pas  moins  que  la  rfutllisation  de  programmes  source  est  un  second  niveau  envisageable, 

3  partir  du  moment  oil  11  se  situe  en  aval  des  Interventions  humalnes. 

Les  directives  donnfes  3  l'fdlteur  de  liens  ftant  fgalement  dferites  par  le  programmeur,  on  aura 
fgalement  intfrft  3  en  rfeupfirer  un  maximum  en  passant  d'un  projet  3  un  autre. 

4.  PREMIERE  GENERATION  DE  LOGICIELS 


Pour  reallser  nos  premiers  logiclels  avlonlques,  nous  avons  done  eu  3  dffinir  1' architecture  du  loglclel, 
sur  les  plans  structurel  et  fonctionnel. 

4.1.  Plan  structurel 

1)  Nlveaux  de  structure 

Nous  avons  dfflnl  une  structure  3  quatre  nlveaux,  sch6matis6e  par  la  figure  ci-dessous. 


-  L'appllcatlon  est  l'ensemble  du  loglclel  implantf  dans  un  calculnteur.  Elle  est  perque  par 
l'utHlsateur  conme  une  bolte  noire,  fchangeant  des  Informations  avec  l'ext§rleur  et  assurant 
une  certalne  fonctlon  de  transfert  entre  ses  entrfes  et  ses  sorties.  Au  niveau  de  la  produc¬ 
tion  de  loglclel,  elle  est  ctractf risf e  par  un  fichier  donnant  la  llste  des  fonctlons  logi- 
cielles  la  composant  et  par  ur.  fichier  de  blnalre  absolu.  Ces  deux  fichiers  sont  references 
avec  le  mfme  non  et  le  mfme  numfro  de  version  (la  seule  difference  ftant  leur  type). 
L'appllcatlon  est  bien  entendu  validfe  par  la  dernlire  ftape  de  test. 

-  La  fonctlon  loglcielle  est  le  premier  niveau  de  dfcoupage.  SI  on  fait  un  parallfle  avec  la 
structure  d'un  materiel,  on  peut  l'asslmiler  3  une  carte  d'un  fquipement.  II  s'agit  d'une 
entitf  assurant  un  r81e  fonctionnel  donnf.  II  lui  est  associf  un  jeu  de  paramftres  en  entrfe 
et  un  jeu  de  paramftres  en  sortie.  Le  soucl  predominant  lors  de  sa  definition  est  l'homogf- 
nfite  du  r81e  qu'elle  doit  jouer.  Le  seul  soucl  informatique  est  la  notion  de  taille  de  logi- 
ciel  associe,  qul  se  situe  g6n6ralement  dans  une  fourchette  de  3000  3  6000  mots.  Avoir  des 
fonctlons  loglcielles  trop  grandes  augmente  leur  dlfficultf,  done  rendent  plus  difficile  le 
test.  Cela  diminue  aussi  leur  chance  de  pouvolr  6tre  standardlsfes.  A  1' inverse,  une  taille 
trop  petite  multiplierait  leur  nombre,  augmentant  alnsi  notablement  les  difficultfs  de  1' inte¬ 
gration  finale  au  niveau  application  et  limlteralt  alors  les  bfnffices  d'une  rfutllisation  de 
certaines  fonctlons  loglcielles  dfjd  valldfes. 

En  ce  qul  concerne  la  production  de  loglclel,  une  fonctlon  loglcielle  est  caractfrisfe  par  un 
fichier  contenant  la  llste  des  piSces  la  constituent  (utilisfe  en  tant  que  directives  pour 
l'fdlteur  de  liens)  et  identifife  par  un  nom  et  un  numfro  de  version.  Chaque  fonctlon  logi- 
cielle  est  validfe  sfparement,  au  cours  de  l'ftape  de  tests  fonctionnels. 


-  Le  module  eat  le  troisiEme  niveau,  de  dEcoupage.  Son  existence  eat  llfie  4  des  modifications 
esaentiellement  informatiques.  Un  module  contient  en  effet  toute  la  partie  d'une  fonction 
logicielle  devant  Stre  exEcutEe  sous  une  m&me  condition  d'activation  (par  exemple  tous  lea 
traltements  cycliques  devant  Stre  exEcutEs  4  une  frequence  donnE). 

gE..£ial,  4UA  t-t*  11  r.E  Jt„e  jii  til  tll_i 

rCle  fonctlonnel  bien  dEfini.  Par  contre,  son  rftle  est  primordial  au  niveau  de  la  technique 
informatique,  car  11  conatitue  une  entltE  d'exEcutlon  :  11  posaide  un  point  d’entrEe  et  un 
point  de  sorlte,  un  jeu  de  paramitres  en  entrEe  et  un  jeu  de  param&trea  en  sortie,.  La  aomme 
dw  palimltna  d 'antifi i i  lt>  JJUffieib  mrialki  d  W  Lufija  I<^IpUII*  tv  tilth 
1' interface  de  cette  fonction  logicielle. 

En  ce  qui  concerne  la  production  de  loglcel,  un  module  est  caractErisE  par  une  entltE  de  code, 
dont  le  rSle  est  d' assurer  l'enchafnement  des  diffErentes  pl&ces  du  module  4  1 'execution  du 
programme . 

-  La  pl4ce  est  le  composant  gl€mentaire,  la  brique  du  logiciel.  Sa  taille  eat  volontairement 
llmltee  de  l'ordre  d'une  clnquantaine  d' Instructions  source.  Une  pi&ce  joue  un  rBle  fonc- 
tionnel  defini,  est  executable  en  un  seul  tenant  (un  point  d'entree,  un  point  de  sortie)  et 
pos84de  une  Interface  d 'entrEe-sortie  bien  deflnle. 

Par  ailleurs,  cheque  piSce  est  compilable  sEparSment .  II  lul  correspond  done,  au  niveau  de  la 
production  de  logiciel,  deux  fichiers  :  fichler  de  langage  source,  et  flchier  Linaire 
relogeable.  Ces  deux  fichiers  portent  le  mSme  nom  et  le  mftme  numEro  de  version  (seul  le  type 
diffSre).  Enfin  chaque  piSce  est  testEe  et  valldEe  sEparEment.  La  taille  llmltEe  d'une  piSce 
permet  d'en  assurer  un  test  quaslment  exhaustlf,  ce  qui  est  primordial  pour  obtenir  la  fiabl- 
litE  recherc'nfie  pour  1' ensemble  de  1' application. 

La  taille  restrelnte  d'une  piSce  fait  qu'elle  joue  un  rSle  bien  dElimitE,  ce  qui  augmente  ses 
possibllltEs  de  rEutilisation  dans  plusleurs  loglciels  diffErents. 


L'ElEment  primordial,  dans  le  cholx  de  mEthodes  de  passage  d' informations  entre  les  diffErentes 
entitfs  de  logiciel,  a  StE  un  soucl  d'optimlsatlon.  Certains  des  loglciels  que  nous  avlons  4 
rEallser  l'Etaient  pour  des  systEmes  EquipEs  d'un  seul  calculateur  principal,  et  le  volume 
mEmoire  Etalt  done  obllgatoirement  limltE  4  64  K.  Par  ailleurs,  le  prlx  de  ces  mEmoires  n'encou- 
ragealt  pas  non  plus  4  de  trop  grandes  largesses.  Enfin,  compte  tenu  de  l'ensemble  des  traite- 
ments  4  rEaliser,  une  certalne  concision  en  charge  de  calcul  Etait  Egalement  nEcessaire. 

Toutes  ces  raisons  nous  ont  amenEs  4  recourir  4  des  zones  de  donnEes  communes,  accesslbles 
directement  par  toute  pi4ce  utlllsatrlce. 

Nous  avons  alors  dEflni  deux  nlveaux  de  commun  : 

-  Un  commun  gEnEral  contenant  toutes  les  donnEes  d' interface  du  calculateur  avec  1'extErieur, 
et  toutes  les  donnEes  en  Interface  des  fonctlons  logicielles. 


-  Des  communs  de  fonction  logicielle,  chacun  regroupant  toutes  les  donnEes  internes  d'une  fonc¬ 
tion  logicielle,  c'e8t-4-dire  en  interface  de  ses  diffErentes  piEces. 


4.2 


Aspect  fonctlonnel 


La  structure  Etant  dEflnle,  il  reste  4  dEfinir  le  rBle  que  doit  assurer  chacun  de  ses  ElEments. 
En  fonction  de  notre  mEthodologie,  MINERVE,  ces  travaux  sont  rEalisEs  au  cours  de  deux  Etapes 
successives. 


-  L'Etape  de  dEfinition  fonctionnelle  conslste  4  reprendre  les  spEciflcations  opErstionnelles 
(le  cahier  des  charges)  du  logiciel  et  4  rEdlger  les  spEciflcations  fonctionnelles  de  celui-ci. 
C'est  done  au  cours  de  cette  Etape  que  sont  dEfinies  les  diffErentes  fonctlons  logicielles. 


-  L'Etape  de  conception  globale  a  pour  rSle  de  dEfinir  les  ElEments  constltutlfs  suivants  du 
logiciel  (modules,  piEces)  et  de  dEfinir  leurs  interfaces. 


En  pratique,  la  rEparcition  en  modules  des  traltements  nEcessalres  pour  l'accomplissement 
d'une  fonction  logicielle  donnEe  ne  pose  pas  de  gros  problEmes.  Le  critSre  "condition 
d'exEcution"  est  en  effet  un  concept  prEcis,  si  bien  que  le  concepteur  n'hEsite  pas  pour 
lmplanter  un  traitetent  dans  le  module  adEquat. 


Par  ailleurs,  Its  pieces  sont  d'une  taille  suffisamment  rEdultes  pour  qu'elles  possident 
gEnEralement  une  bonne  cohErence  fonctionnelle. 
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Par  contre,  la  definition  dee  fonctlona  loglclelles  eat  plus  complexe.  Elle  recoupe  en  effet 
des  preoccupations  d' analyse  du  probldme  1  tralter,  et  de  synthSse  1  un  niveau  relatlvement 
6iev6  .  Lea  crltdres  de  cholx  sont  multiples,  et  le  concepteur  dolt  en  fait  obtenlr  le 
mellleur  compromls  entre  plusleurs  facteurs  dont  certains  sont  contradlctolres  : 

-  Posslbllltes  d'adaptatlon  du  loglclel  3  des  evolutions  opdratlonnelles  (modification,  sup¬ 
pression  ou  ajout  de  modes  operatlonnels)  ou  des  evolutions  des  equlpements  du  systdme 
(modification,  suppression  ou  refonte  de  certains  d'entre  eux), 

-  Isolement  des  traltements  dependant  dlrectement  de  chacun  des  autres  dqulpements  du  systdme, 
par  rapport  aux  traltements  caractdrlatlques  d'un  mode  operatlonnel  dans  le  but  de  standar- 
dlser  ces  dernlers, 

-  Soucl  d' optimisation,  par  mlse  en  commun  et  Implantation  unique  dans  le  calculateur  de  tral¬ 
tements  necessalres  3  l'executlon  de  plusleurs  modes  operatlonnels, 

-  Possiblllte  de  reallser  des  llvralsons  partlelles,  c'est-3-dire  de  llvrer  un  loglclel 
compose  d'un  nombre  rddult  de  fonctlons  loglclelles,  qul  permette  neanmolns  au  systdme 
d'executer  un  certain  nombre  de  missions  operatlonnelles, 

Cette  possiblllte  est  Importance  car  elle  autorlse  une  Imbrication  des  phases  de  specifi¬ 
cations,  de  realisation  du  loglclel,  et  d' Integration  du  systdme,  reduisant  alnsl  les  d€lals 
de  ddveloppement, 

-Possiblllte  de  deflnlr,  pour  chacune  des  fonctlons  loglclelles,  des  modes  de  fonctlonnement 
degrades-  Le  r81e  de  ceux-cl  est  de  fournlr  les  m6mes  paramdtres  de  sortie  que  dans  le  mode 
de  fonctlonnement  normal  (avcc  une  precision  mains  bonne)  lorsqu'iin  certain  nrmbre  d' Infor¬ 
mations  en  entree  sont  elles-mSme  d6gradees  ou  manquantes,  Cela  permet  d'assurer  une  contl- 
nulte  de  fonctlonnement  du  systdme  en  cas  de  panne  d ' equlpements, 

Appllquer  aux  loglclels  avlonlques,  ces  notions  ont  conduit  3  deflnlr  quatre  grands  types  de 
fonctlons  loglclelles  : 

-  Les  fonctlons  loglclelles  "de  servitude",  dont  le  r81e  est  de  permettre  le  fonctlonnement 
du  calculateur  (monlteur,  autosurvelllance)  ou  du  systdme  (gestlon  des  bus,  surveillance 
des  equlpements  et  slgnallsatlon  de  leurs  pannes), 

-  Les  fonctlons  loglclelles  "g6nerales" ,  dont  le  fonctlonnement  est  Independant  ou  peu  depen¬ 
dant  du  mode  systdme  en  cours.  Certaines  assurent  une  Interface  avec  les  capteurs  :  prdtral- 
tement  des  donndes  en  entree  du  calculateur  de  faqon  3  eiaborer  les  Informations  sous  une 
forme  Interne  standardlsde,  mals  aussl  mlse  en  forme  definitive  des  Informations  retourndes 
3  ces  mdmes  capteurs  pour  en  commander  le  fonctlonnement,  D'autres  assurent  des  fonctlons 
communes  3  plusleurs  modes  operatlonnels  dlfferents,  comme  l'acqulsltlon  d'objectlfs  par 
exemple, 

-  Les  fonctlons  loglclelles  "sp6clf lques"  des  modes  operatlonnels  devant  fitre  assurdes  par  le 
systdme  :  navigation,  dlffdrentes  condultes  de  tlr  des  armes  air-air  et  air-sol,  reconnais¬ 
sance,  aide  3  la  maintenance  sol,  etc,,, 

-  Enfln,  les  fonctlons  loglclelles  "de  synthdse" ,  assurant  la  coordination  des  dlffdrentes 
fonctlons  prdcddentes  pour  obtenlr  un  fonctlonnement  coherent  du  loglclel  global.  Dans  ce 
cadre,  sont  en  partlculler  assurdes  les  synthdses  des  dlffdrentes  Informations  3  destination 
des  dqulpements  multi-modes  :  postes  de  commandes,  viseurs  tdte  haute  ou  tdte  basse.  Ces 
synthdses  sont  dlabordes  3  partlr  des  informations  d61ivr6es  par  les  diffdrentes  fonctlons 
gdndrales  ou  spdclf lques  actives, 

A. 3,  Bilan  de  cette  premldre  approche 

Nous  avons  rdallsd,  entre  1977  et  1982,  plus  d'une  qulnzalne  de  loglclels  pour  des  systdmes 
dlffdrents  selon  les  prlnclpes  ddcrlts  cl-dessus, 

Ceux-cl  se  sont  tou Jours  av6r6s  applicables,  et  la  structure  des  premiers  loglclels  n'a 
Jamals  dtd  remise  en  cause  par  la  modification  d'autres  dqulpements,  nl  par  l'ajout  de  nou- 
velles  fonctlons  operatlonnelles.  Cette  modularitd  a  dtd  dgalement  un  dldment  preponderant 
dans  la  possiblllte  d'lntdgrer  les  trds  nombreuses  demandes  de  modifications  que  nous  dvo- 
qulons  au  paragraphe  2,  De  mdme,  plusleurs  applications  diffdrentes  ont  pu  dtre  dddultes  les 
unes  des  autres  3  un  coQt  beaucoup  plus  falble  que  celul  du  ddveloppement  de  l'applicatlon 
m3  re. 


Cependant,  lorsqu'on  arrive  au  niveau  du  detail,  la  situation  n'est  pas  aussi  bonne  que  l'on 

pourrait  1’espErer,  11  n'exlste  guSre  d'ElEments  rigoureuseaent  ldentiquea  entre  deux  logiciels. 

Les  applications  sont  dfduites  les  unes  des  autres,  plus  que  composEes  4  partir  d'ElEments 

communs . 

Ce  phEnomEne  tlent  3  trols  causes  princlpales  : 

1)  tin  problEme  spEclf iquement  informatlque,  tenant  de  l’utlllsation  de  commune  pour  assurer 
les  Echanges  d’lnformatlon  entre  les  diffErentes  entltEs  de  logiciel.  Le  commun  gEnEral 
entre  autre  est  spEcifique  de  chaque  application,  or  il  influence  le  code  blnaire  relo- 
geable  de  chaque  piSce.  La  rEcupEratlon  ne  peut  done  se  faire  au  mieux  qu'au  niveau  de  lan- 
gage  source. 

2)  Des  Evolutions  de  dEtall  trSs  nombreuses  en  passant  d'un  systEme  3  un  autre. 

Ces  Evolutions  portent  3  la  fols  sur  la  dgfinltlon  des  autres  gqulpements  du  systEme 
(nous  avons  13  flnalement  beaucoup  plus  3  tenlr  compte  des  petltes  "amEl locations"  que  de 
changeaent  complet  d'un  type  d'Equlpement)  et  sur  les  spgclflcatlons  des  modes  opgration- 
nels •  Toutes  ces  Evolutions  de  dEtail,  lorsqu'elles  sont  cmtulEes,  font  qu'll  devlent 
difficile  de  conserver  lntacts  de  nombreux  ElEments  du  loglclel. 

3)  Un  manque  de  perception  de  la  structure  Interne  du  loglclel  exlstant  par  les  utlllsateurs , 
que  ce  solt  au  niveau  des  gqulpes  Etabllssant  les  spgclflcatlons  opgrationnelles  qu’au 
niveau  des  gqulpes  d'essals  du  systEme  au  banc  d'lntggration  et  en  vol.  Le  manque  de 
perception  est  probablement  lig  en  partie  3  1 ’aspect  un  peu  rEbarbatlf  de  la  documentation 
assoclEe  au  loglclel  pour  des  non  lnformaticlens.  Le  rEsultat  est  sQrement  une  senslblll- 
satlon  rgdulte  3  l'aspect  rEutllisatlon  de  partie  de  logiciels  exlstants  au  moment  de  la 
dgfinltlon  d'un  nouveau  systSme. 


5.  EVOLUTIONS  RECENTES 


Le  rEexamen  de  1 'architecture  de  nos  logiciels  avlonlques  a  EtE  provoquE  par  l'occurence  simultanEe  de 
plusleurs  EvSnements  de  nature  dlffErente  : 

-  DEmarrage  d'une  application  nouvelle,  devant  Evoluer  largement  dans  l’avenir.  Cette  application  sers 
en  fait  la  base  (aussi  blen  sous  l'aspect  missions  possibles  au  jeu  d' gqulpements)  d'une  famllle  de 
systEmes,  base  3  laquelle  devront  pouvolr  s'ajouter  de  nombreuses  options. 

-  Accroissement  des  posslbllltEs  du  calculateur,  la  tallle  mEmoire  devant  dEsormals  dEpasser  le  seuil 
des  64  K  mots.  Cela  amenalt  3  reprendre  certains  ElEments,  en  particulier  Etendre  la  capacltE  d'adres- 
sage  de  la  machine  virtuelle  et  adapter  le  programme  d'Edltions  de  liens. 

-  Souci  de  plus  en  plus  Important  de  pouvolr  rEcupgrer  IntEgralement  des  parties  de  logiciel  existant, 
pour  en  tirer  un  maximum  de  bEnEflce  aussi  bien  au  niveau  de  la  rEall.satlon  du  logiciel  que  de 

1' intEgration  et  la  validation  du  SystEme  de  Navigation  et  d'Armement  global. 

Une  Equipe  commune  maltre  d'oeuvre  du  systEme  -  rEallsateur  du  logiciel  a  lone  menE  une  Etude  sur  ce 
problEme.  La  premiEre  Etape  a  consists  3  dEflnir  clairement  les  objectifs  nouveaux  que  l'on  cherchait  3 
atteindre  par  la  modularltE  du  logiciel. 

Elle  s 'est  poursulvle  par  la  dEflnltlon  de  nouvelles  solutions  : 

-  sur  le  plan  structurel, 

-  sur  les  plans  fonctionnel  et  opErationnel. 

Enfin,  les  moyens  d'une  meilleure  circulation  de  l'information  entre  spgcif icateur  et  rEallsateur  du 
logiciel  ont  EtE  Etablis. 


5.1.  DEflnltlon  de  nouveaux  objectify 

REcupErabllltE  du  loglclel  :  elle  con3titue  1'objectif  le  plus  prioritaire.  Cette  rEcupErabilitE 
doit  Etre  IntSgrale,  et  suffisamment  formalisEe  pour  qu'elle  puisse  Eviter  une  nouvelle  validation 
que  ce  solt  au  niveau  des  essals  d'lntggration  du  systEme  au  sol  ou  au  niveau  des  essals  en  vol. 
Une  condition  est  done  qu'il  doit  y  avoir  la  meilleure  correspondence  possible  entre  les  entitSs 
opgrationnelles  (les  ElEments  du  dEcoupage  de  l'application  abordEe  avec  le  point  de  vue  de  l’uti- 
lisateur)  et  les  entitSs  fonctionnelles.  En  outre,  il  est  souhaitable  de  pouvolr  donner  3  ces 
entitEs  fonctionnelles  les  posslbllltEs  de  rEglage,  clairement  IsolEes,  de  faqon  3  pouvolr  les 
adapter  3  chaque  cas  particulier  sans  en  reprendre  la  programmatlon  proprement  dlte. 


Amelioration  de  la  visibility  du  loglclel  pour  le  specif lcateur  :  celul-ci  devra  en  effet  apprA- 
hender  la  structure  Interne  du  loglclel,  pour  dlffSrentes  raisons  : 

-  Adapter  les  tests  d' Integration  du  systAme,  en  ne  consid€rant  plus  le  loglclel  comme  une  seule 
"bolte  noire",  mals  comae  plusleurs  JuxtaposAes.  Le  but  est  de  rfdulre  le  nombre  de  tests  n6ces- 
salres  eu  niveau  FystSme  aprAs  une  modification  du  loglclel. 

-  Prendre  en  compte  la  structure  du  loglclel  pour  concevolr  des  evolutions  de  systAme  (modifications 

ou  ajouts),  de  faqon  A  en  mlnimlser  les  coQts. 

Une  demande  precise  etalt  qu’ll  fallait  pouvolr  6tabllr  les  correspondances  entre  les  differents 
elements  du  decoupage  au  niveau  operatlonnel,  et  les  differentes  entlt6s  du  loglclel. 

Contlnulte  avec  les  applications  exlstantes  :  la  prise  en  compte  de  nouveaux  objectlfs  devait  se 
falre  en  tenant  compte  de  l'exlstant,  aussl  blen  pour  ce  qul  concernait  le  contexte  de  realisation 
(moyens  de  developpement  et  de  test  ;  en  partlculier  11  n'y  avalt  pas  d’ autre  cholx  possible  que 
de  continuer  A  utiliser  le  conpllateur  LTR,  le  langage  de  haut  niveau  de  nos  prAcAdentes 
applications,  blen  AprouvA)  que  pour  des  problAmes  de  codt  et  de  deials  :  11  etalt  lnenvlsageable 
de  reallser  In  extenso  une  application  nouvelle. 

5.2.  Evolutions  sur  le  plan  structure! 

Elies  sont  au  nombre  de  3  : 

-  Creation  d'un  clnquiAme  niveau  de  d6coupage,  entre  application  et  fonctlon  logicielle  :  le  pro¬ 
gramme. 

-  Definition  d’un  langage  de  description  de  modules,  et  realisation  d'un  lnterpreteur  aglssant  en 
tant  que  preprocesseur  du  compllateur  LTR. 

-  Extensions  de  la  machine  vlrtuelle  des  calculateurs  avec  un  mode  d'adressage  "paramAtre" . 


5.2.1.  ClnquiAme  niveau  de  decoupage  :  le  programme 

L'objectlf  est  de  pouvolr  dlvlser  1' application  totale  en  un  certain  nombre  d'eiements 
rlgoureusement  Independants  au  niveau  de  1' execution,  slmplement  Juxtaposes  au  seln  de 
la  memolre  du  calculateur. 

De  faqon  A  assurer  une  parfalte  Independence,  et  blen  que  cela  auralt  6t6  possible  avec  le 
calculateur  utilise,  un  programme  ne  peut  acceder  dlrectement  aux  donnees  d'un  autre 
programme . 

La  seule  posslblllte  d'6change  d' Information  conslste  A  falre  appel  au  supervlseur,  qul  gAre 
une  zone  de  la  memolre  affectee  spAcialeinent  A  cet  usage  par  des  mecanlsmes  de  lecture/ 
ecriture  dans  des  flchlers. 

Un  programme  est  entlArement  autonome  :  lorsqu'll  est  actlf,  11  dolt  gArer  l'ensemble  des 
ressources  du  calculateur  (coupleurs,  Interruptions)  et  du  systAme  (Aqulpements) •  Les  commu¬ 
tations  de  programme  sont  assurAes  par  le  supervlseur. 


SUPERV1SEUR 


Gestlon  flchler 


Zone  memolre 
"flchler" 


Lecture/ 
ecriture  flchler 


Activation 


Programmes 


La  structure  Interne  d'un  programme  reste  celle  des  applications  dAcrltes  au  chapltre  prece¬ 
dent  :  11  reste  divise  en  fonctlons  loglclelles,  modules  et  plftces. 

La  decomposition  des  differents  programmes  d'une  mAne  application  peut  conduire  A  la  defini¬ 
tion  de  fonctlons  loglclelles  ldentiques.  Dans  ce  cas,  celles-ci  ne  seront  alors  lmplantAes 
qu'une  seule  forts  dans  la  memolre  du  calculateur. 


- 


Du  point  de  vut  de  l'dcriture  du  loglclel,  le  programme  aera  caractCrisd  pat  : 

-  Dn  certain  noabre  de  pidces  en  langage  source  qul  lui  sont  spddflques,  contenant  essen- 
tiellement  le  code  de  haut  niveau  pour  l'extcutlon  (description  des  processus,  gestlon  des 
coupleurs ,  etc), 

-  La  llste  des  fonctlons  logicielles  pernettant  d'exdcuter  lea  dlffdrentes  tSches  qu'll  dolt 
assurer. 

Le  programme,  dtant  entldrenent  autonome,  eat  done  un  fitment  de  recuperation  absolu  entre 
deux  applications.  Chacun  pourra  dtre  valldd  sdpardnent,  et  le  seul  contrfile  3  assurer  pour 
une  nouvelle  application  composde  1  partir  de  programmes  precedemment  exlstants  et  valides 
sera  celul  de  la  presence  effective  des  programmes  desires  dans  la  memolre  du  calculateur. 

D'un  point  de  vue  pratique,  11  a  Itf  decide  de  falre  corresponds  un  programme  3  chaque  con¬ 
figuration  d'emports  ddfinie  par  le  Systime  de  Navigation  et  d'Armements,  c'eat-3-dire  3 
chaque  mission  opdratlonnelle  executable  par  l'avlon. 

5.2.2.  Langage  de  description  de  nodules 

Les  buts  poursuivis  sont  d'ameilorer  la  lislblllte  du  loglclel,  et  de  suppriner  le  recours  3 
un  commun  gCnCral  pour  implanter  les  donnees  Interface  entre  fonctlons  logicielles.  Par 
allleurs,  nous  tenions,  comme  nous  l'avons  6crlt  plus  haut,  3  continuer  3  utlllser  le  meme 
langage  de  programmation,  le  LTR. 

Le  langage  de  description  de  nodules  est  Inspire  des  notions  les  plus  rdeentes  en  langage  de 
programmation.  Sa  syntaxe  permet  de  ddflnlr  des  modules,  en  lsolant  deux  parties  nettement 
dlstlnctes  : 

-  1 'Interface  du  module,  o&  sont  ddcrits  : 

.  les  donndes  :  sens  (entree  ou  sortie),  type,  format,  Implantation... 

.  les  points  d'entrde  accesslbles  de  l'extdrleur  3  1' execution.  La  rigle  d'utllisatlon 
gdndrale  est  qu'll  y  alt  un  seul  point  d'entrde  par  module.  Cependent,  la  possibility 
d'en  ddflnlr  plusleurs  peut  permettre  de  cholslr  3  un  niveau  supdrleur  (celul  du 
programme)  entre  deux  traltements  different*  sur  la  m3me  Interface. 

-  Le  corps  du  module,  constltud  par  : 

.  les  donndes  Internes 

•  le  code  du  module,  pour  lequel  la  syntaxe  est  la  mime  que  celle  du  langage  LTR.  En 
pratique  dans  nos  applications,  ce  code  est  un  squelette  appelant  les  dlffdrentes 
pl3ces,  celles-ci  dtant  computes  sdpardment. 

Le  prdproceascur  de  modules  transforme  du  source  Ccrlt  en  langage  de  description  de  modules 
en  un  source  compatible  de  la  syntaxe  LTR,  qul  est  alnal  exploitable  par  la  mCme  chalne  de 
production  que  le  reste  du  loglclel.  Cette  transformation  peut  itre  rdalisde  sans  qu'll  alt 
dtd  ndeessaire  de  modifier  le  compllateur  LTR  exlstant. 

Enfln,  nous  sommes  en  train  de  ddvelopper  un  analyseur  de  modules,  cet  outll  aura  pour  r61e 
de  vdrlfler  la  coherence  des  Interfaces  des  modules  au  niveau  d'un  programme,  et  d'ftabllr 
des  11..-**  de  reference  crolsdet  des  donnCes.  Le  langage  de  description  de  module  est  en  ef- 
fet  utilise  cours  de  l'Ctape  de  conception  globale  du  loglclel,  et  11  est  partlcullfere- 
ment  intdressant  de  pouvolr  contrfiler  d3s  cette  dtape  la  coherence  de  la  definition  des 
Interfaces. 

5.2.3.  Extension  de  la  machine  vlrtuelle  du  calculateur 


L'objectif  lei  etalt  d’arrlver  3  une  rCcupdrablllte  parfalte  au  niveau  des  pldces  de 
loglclel,  en  s'affranchlssant  mCme  du  probldme  d'identitd  des  non a  symbollques  des  varia¬ 
bles  Interface.  Le  seul  moyen  rdel  d'y  parvenlr  est  de  ne  concevolr  ces  pldces  que  comme 
des  sous-programmes  travalllant  excluslvement  sur  des  llstes  d' arguments.  Cette  mCthode 
est  moins  performante  que  l'utilisatlon  de  conmuns.  Cependant,  11  dtalt  admls  de  dCplacer 
le  point  d'dqullibre  entre  optimisation  et  adpatabilite  du  loglclel  pour  aller  dans  le 
sens  d'une  plus  grande  souplesse. 

C'est  pourquoi,  nous  avons  adjoint  3  la  machine  vlrtuelle  des  calculateurs  un  mode 
d'adressage  "paramitre",  optlaisant  cette  mdthode  de  transmission  d'arguments.  Les  Instruc¬ 
tions  utilisant  ce  mode  d'adressage  restent  sur  2  octets  (le  calculateur  est  une  machine 
16/32  bits),  ce  qul  Unite  le  taux  d'expanslon  lnduit. 
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5.3.  Evolutions  sur  le  plan  fonctlonnel 

Avoir  une  structure  offrant  des  posslbllltEs  de  rSutillsation  de  parties  de  logiclel  existant  ne 
sufflt  pas.  En  effet,  l'utillsateur  dEslre  rficupgrer  une  fonctlon  de  son  avion,  correspondant  A  une 
entitS  sur  le  plan  opEratlonnel.  II  est  done  nEcessaire  que  le  rEallsateur  ait  une  bonne  connais- 
sance  de  cet  aspect  opEratlonnel.  A  1' Inverse,  le  spEcif lesteur  dolt  adopter  une  certalne  disci¬ 
pline,  et  prendre  en  compte  la  nature  et  la  structure  du  logiclel  exlstant  avant  de  dEfinlr  un 
nouveau  systAme,  pour  decider  en  toute  connalssance  de  cause  de  demander  des  Evolutions.  C'est 
pourquoi,  11  est  primordial  qu'un  veritable  dialogue  s'Etabllsse  entre  spEcif lcateur  et  rSali- 
sateur. 

La  premiAre  Etape  a  consistE  A  retenir  l'utilisatlon  d'un  langage  commun,  pour  dEcomposer  le  pro- 
blAme  3  traiter  sous  les  deux  aspects  opEratlonnel  et  fonctlonnel.  Un  langage  graphique  a  EtE 
choisi.  II  entratne  en  effet  une  plus  grande  concision,  et  sa  syntaxe  est  suf f isamment  simple 
pour  qu'il  soit  comprEhenslble  aprAs  une  formation  vralment  minlme.  De  plus  l'aspect  visuel  est  A 
privilEgier,  A  partir  du  moment  ofl  l'on  dEsire  travailler  avec  des  non  info rmatic lens. 

Ce  langage  est  d'abord  utllisE  pour  aborder  le  problAme  sous  l'aspect  opEratlonnel.  II  s'agissait 
en  effet  d'aller  plus  loin  que  le  dEcoupage  tradltlonnel ,  dont  le  critAre  Stait  gEnEralement  une 
tranche  de  temps,  comprise  entre  une  action  du  pllote  (l'enclenchement  d'un  mode)  et  une  autre 
(la  dEsElectlon  de  ce  mode).  La  dEcoraposition  a  pour  but,  au  contraire,  de  faire  apparaltre  des  en- 
titEs  opErationnelles,  qui  rEalisEes  en  parallAle,  condulsent  A  obtenlr  un  mode  complet.  Un  des 
points  lmportants  A  ce  niveau  est  de  sSparer  ce  qul  dSpend  du  type  de  l'avion,  par  rapport  A  ce 
qui  est  caractEristlque  de  la  mission.  Cela  conduit  done  A  dSflnir  une  vfiritable  modularltE  sur  le 
plan  opEratlonnel,  ce  qui  est  en  fait  une  condition  impSrative  pour  tapSrer  obtenlr  une  modularltE 
du  logiclel.  Cette  Etape  est  du  ressort  du  spSclflcateur  du  logiclel. 

La  deuxiAme  Etape  consiste  A  rgaliser  la  dEcomposltlon  fonctionnelle  du  problAme  avec  le  mEme 
langage.  Les  critAres  Etant  dlffErents,  cette  dEcomposltlon  ne  sera  pas  la  mEme  que  prEcEdemment . 

La  correspondence  entre  chaque  ElEment  de  la  dEcomposltlon  opErationnelle  et  les  ElEments  de  la 
dEcomposltlon  fonctionnelle,  ainsl  que  la  correspondance  Inverse,  sont  alors  Etablles. 

Cela  permrt  done  au  spEclflcateur  comme  au  rEallsateur  de  juger  de  1'adEquatlon  de  la  dScompo- 
sition  fonctionnelle  aux  problAmes  de  l'utillsateur  (molns  un  ElEment  opEratlonnel  sera  EclatE 
entre  dlffErents  ElEments  fonctionnels,  mellleure  sera  la  dEcomposltlon),  et  de  dEterminer  les 
corrections  nEcessalres  avant  de  commencer  l'Ecriture  du  logiclel. 

Cette  approche  permet  de  dEfinir  des  entltEs  fonctlonnelles,  done  par  la  suite  des  entltEs  de 
logiclel,  dont  les  frontiAres  correspondent  A  des  notions  opErationnelles.  L'Etape  sulvante  consis¬ 
te  A  standardlser  ces  entltEs,  leur  dEflnissant  un  rBle  et  des  Interfaces  faisant  au  maximum  ab¬ 
straction  de  l'appllcation  dans  le  contexte  de  laquelle  elles  sont  dEfinles.  Cette  standardisation 
ne  peut  se  faire  que  par  coopgration  entre  spSclflcateur  et  rEallsateur,  car  elle  doit  prendre  en 
compte  aussl  bien  les  Evolutions  prEvlslbles  ou  envlsageables  des  systAmes,  que  les  contralntes  de 
rgallsatlon.  Elle  peut  s'accompsgner  de  la  dSfinitlon  de  paramAtres  de  rEglage  de  la  fonctlon, 
permettant  de  1' adapter  A  des  cas  particulars. 

Cette  approche  nous  a  conduit  3  modifier  certalnes  solutions  (pas  toutes,  heureusenent  !)  adoptEes 
prEcEdemment.  L'effort  a  surtout  portE  sur  les  traltements  HEs  aux  Equipements  multimodes 
(viseurs,  postes  de  commande),  et  ceci  aussl  bien  sur  le  plan  opEratlonnel  que  sur  le  plan 
fonctlonnel. 

Elle  a  en  outre  l'Snorme  avantage  de  permettre  au  maltre  d’oeuvre  du  systAme  de  mleux  connattre 
la  structure  du  logiclel.  Une  consgquence  dlrecte  en  est  la  possibilltS  d'en  tenir  compte  pour 
la  conduite  des  essais  d'intEgration  du  SystAme  :  elle  permet  d ’apprShender  le  logiclel  comme 
plusieurs  entltEs  travaillant  ensemble,  et  non  comme  une  seule.  II  devient  dSs  lors  possible  de 
recourir  A  une  approche  sSlective  des  test  A  repasser  en  cas  de  modification  d'une  partie  du 
logiclel.  Cela  va  amener  les  Squipes  d'essais  A  contr&ler  systAmatiquement  des  Informations  inter¬ 
nes  du  calculateur,  et  non  plus  slmplement  des  Interfaces  entre  celui-ci  et  les  autres  Equipe¬ 
ments  du  systAme. 
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6.  CONCLUSION  ET  PERSPECTIVES 


La  modularity  n’est  qu’un  des  aspects  de  la  production  d'un  loglclel.  C’est  cependant  un  £l£ment 
primordial  dans  la  recherche  d'un  abalssement  du  prix  de  revlent  en  pernettant  la  r£utlliaation 
d'£l£ments  logiciels  ezlstants  et  valld£s.  C’est  i  notre  avis  le  second  service  qu'un  rSallsateur 
pulsse  rendre  J  un  utlllsateur,  le  premier  restant  de  lul  fournlr  un  loglclel  qui  fonctionne 
correct ement • 

Les  dlff£rents  outlls  et  mSthodes  d£crlts  dans  ce  document  sont  actuelleaent  utilises  sur  un  loglclel  en 
cours  de  ddveloppement .  II  faut  done  attendre  l’£preuve  du  temps  pour  voir  si  tous  les  objectlfs  flx£s 
seront  tenus.  Notre  experience  passde  nous  peraet  cependant  d'esp£rer  un  taux  de  r£usslte  slgnlflcatlf . 
En  partlculler,  nous  attendons  beaucoup  de  renforcement  des  dialogues  entre  utlllsateur  et  r£allsateur. 

Notre  effort  a  surtout  port£  sur  les  posslblllt£s  de  r£cup£ratlon  de  code  proprement  dlt.  Ca  n’est  en 
fait  qu'un  des  aspects  de  la  production  du  loglclel,  les  autres  £tant  la  documentation  et  les  flchlers 
de  validation;  Nous  avons  £galement  mis  en  place  un  certain  nombre  de  moyens,  essentlellenent  des  outlls 
unlversels  graphlques,  de  traltement  de  textes,  et  d’archlvages.  II  ne  s'aglt  pourtant  que  de  solutions 
partlelles,  forc£ment  llmlt£es. 

La  solution  r£elle  vlendra  avec  1 ’utilisation  d’un  “Atelier  Int£gr£  de  G£nie  Loglclel"  prenant  en  compte 
les  aspects  de  la  production  de  loglclel,  depuls  les  Sp£clficatlons  jusqu'au  sulvi  en  exploitation.  En 
partlculler,  en  facllltant  la  mise  en  oeuvre  de  langages  de  sp£clflcatlons,  11  devralt  permettre  une 
am£lloratlon  de  la  quallt£  de  celles-cl,  ce  qul  ne  pourra  que  renforcer  leur  stability. 
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DISCUSSION 


K.F.Boecking,  Ge 

You  presented  a  modular  software  system  and  talked  about  software  validation.  What  is  the  exact  way, 
especially  in  a  modular  system,  you  make  sure  that  the  algorithms  do  what  you  hope  they  are  doing?  Do  you 
test  all  input  conditions? 

Reponse  d’Auteur 

Notre  methodologie  de  developpement  du  logiciel  pr£voit  plusieurs  niveaux  de  test.  En  particular  les  tests 
unitaires  permettent  de  controler  le  fonctionnement  de  chaque  piece  de  logiciel  prise  separement,  et  les  “tests 
fonctionnels”  permettent  de  controler  le  fonctionnement  de  chaque  fonction  logicielle.  Ces  tests,  realises  en 
usine,  concernent  le  logiciel  et  lui  seul.  C’est  pourquoi  ils  peuvent  etre  tres  profonds,  et  une  tres  grande  variete 
de  jeux  d’essais  peuvent  etre  passes,  notamment  grace  a  une  “baie  de  validation  de  logiciel”  qui  nous  permet  de 
faire  fonctionner  le  logiciel  dans  des  conditions  reelles. 

Le  logiciel  est  ensuite  pris  en  main,  au  meme  titre  que  les  autres  equipements,  par  le  maitre  d’oeuvre  du  systeme 
qui  conduit  l’integration  de  ces  differents  equipements  par  des  essais  en  vol.  Un  des  interets  de  notre  approche 
est  que  les  equipes  chargees  de  cette  integration  vont  pouvoir  gonsiddrer  le  logiciel  comme  plusieurs  boites 
hoirtl.  «1  In*:  pkic  rw.w. « i  Et  nilgai  t  Jkt-'Jvtt'i'ic' si  inirtn  -i  Ju  AW*  tt*  t  low  valdw 
separement  les  entitds  composant  celui-ci. 


W.McKinlay,  UK 

I  am  interested  in  the  first  part  of  the  design  process  involving  a  dialogue  between  the  operator  and  the  design 
team.  Is  this  accomplished  using  a  formal  design  language?  At  what  level  is  it  mechanized  using  computers  as 
opposed  to  manually  or  by  discussion? 

Rlponse  d’Auteur 

Comme  nous  l’avons  precise  au  cours  de  l’expose,  un  meme  langage  de  conception  graphique  est  utilise  par  le 
tjJfi'iPI  BKwr  lu  k*,V£u|  putn  HUJtotuii.  JtewnpotiU*!  OsfmCt opfctlAkJlibd, 
decomposition  sous  l’aspect  fonctionnel.  La  decomposition  operationnelle  fait  partie  integrante  des 
Specifications  Operationnelles  du  logiciel,  constituanl  le  cahier  des  charges,  pour  la  realisation  du  celui-ci. 

Par  contre,  ce  langage  n’est  pas  utilise  par  la  redaction  des  specifications  globales  du  Systeme  de  Navigation  et 
d’Armements,  et  n’est  done  pas  utilise  pour  le  dialogue  utilisateur-specificateur. 
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SUMMARY 


y*Due  to  the  use  of  new  materials,  the  enlargement  of  the  electromagnetic  environ¬ 
ment,  the  increasing  susceptibility  of  electronic  components  and  the  rising  dependence  on 
satisfactorf ly  functioning  electronics,  greater  attention  must  be  paid  to  electromagnetic 
effects  in  modern  aircraft  development. 

The  increase  in  the  scope  of  problems  in  comparison  with  the  past  and  the  possibilities 
which  can  be  recommended  for  their  solution  are  presented  in  this  paper.  -^7 


1 .  INTRODUCTION 

The  following  aircraft  structures  with  their  respective  era-oi.  iented  equipment, 
environment  and  significane  of  the  electronic  components  for  the  aircraft  are  taken  into 
consideration  in  this  context: 

-  pure  metal  structure  (aluminum) 

-  mixed  structure  (aluminum  structure  with  avionic  access  doors  or  panels  made  of 
glass  reinforced  plastics  =  GRP  or  carbon  fiber  composite  =  CFCj  if  larger  parts 
are  made  of  e.g.  CFC,  such  a  part  shall  be  considered  as  a  CFC-structure 

-  CFC-structures. 


2.  SURVEY  OF  THE  ELECTROMAGNETIC  EFFECTS  CONSIDERED 

In  order  that  an  aircraft  may  fulfil  its  tasks  reliably  and  satisfactorily,  the 
following  problems  with  reference  to  the  electromagnetic  effects  must  be  solved  (Fig.  1): 

internal  electromagnetic  compatibility,  i.e.  the  equipment  in  the  aircraft  must 
not  interfere  with  itself. 

-  external  electromagnetic  compatibility,  i.e.  satisfactory  functioning  must  be 
ensured  even  in  a  certain  radiation  environment. 


lightning  protection 

Merely  the  influence  on  the  electrical  system  is  considered  at  this  point. 
Moreover,  only  a  direct  hit  is  taken  into  account,  since  this  also  covers  the 
effects  of  a  nearby  stroke  of  lightning. 

-  hardening  with  respect  to  the  nuclear  electromagnetic  pulse  (NEMP). 


Electrostatics  are  neglected  here,  since  the  problems  occurring  in  this  connection 
can  be  solved  relatively  easily  irrespective  of  the  i.-ethod  of  construction.  -  Considera¬ 
tion  of  internal  compatibility  is  restricted  to  the  most  important  effect  in  conjunction 
with  the  airframe  construction,  namely  on  the  coupling  between  antennas  and  internal 
electrical  system/electronics.  The  internal  compatibility  can  thus  be  dealt  with  together 
with  the  external  compatiblity  in  the  following  section. 

3.  PRINCIPLE  UNDERLYING  INTERFERENCE  WITH  THE  EQUIPMENT  AND  ASSURANCE  OF  COMPATIBILITY 
Interference  takes  place  basically  as  shown  in  Fig.  2. 

Interference  signals  are  coupled  i  ito  the  system  along  the  relevant  paths  from  the 
interference  source.  They  spread  throughout  the  system  and  reach  the  equipment  in  the 
form  of  fields  and  conductive  interferences.  It  depends  on  the  susceptibility  of  the 
equipment  in  comparison  with  the  levels  of  the  incoming  interferences  as  to  whether 
(permanent)  destruction,  (temporary)  interference  or  no  effect  at  all  occur. 


Possible  interference  sources  shown  in  Fig.  2  are  considered:  EMC,  lightning  stroke 
and  NEMP. 


The  compatibility  of  the  equipment  is  ensured  by  being  protected  in  accordance  «uu 
the  incoming  levels  and  their  significance  for  the  system  (whereby  these  incoming  levels 
must  be  kept  as  low  as  possible  through  protective  measures  at  system  level).  Basically, 
equipment  critical  with  respect  to  safety  is  protected  against  lightning,  NEMP  and  EMC 
effects,  equipment  critical  with  respect  to  the  mission  against  NEMP  and  EMC,  and  all 
other  equipment  solely  against  EMC.  -  A  safety  margin  of  20  dB  is  required  in  connection 
with  EMC  for  equipment  critical  with  respect  to  safety,  and  of  only  6  dB  for  all  other 
equipment. 


4.  JHHUC.B  i'U  THb  Ebfci.TRll.Ali  o*S'ifcM/ SufctlKjKllS  AS  A  FUNbllUN  ot  TfcCHNibAb  UfcVbbUl'Mfc'hi 
IN  AIRCRAFT  CONSTRUCTION 


4.1  General 

The  airframe  structures  (metal,  mixed,  CFC)  listed  in  Section  1  correspond  to 
advanced  developments  both  in  terms  of  technology  and  of  time.  Combining  these  aircraft 
types  with  the  pertinent  era-oriented  electromagnetic  environment  and  electrical  system/ 
electronics  permits  deriving  qualitative  statements  concerning  a  change  of  the  danger 
entailed  by  the  electromagnetic  effects  as  a  function  of  time  or  of  technical  develop¬ 
ments,  respectively.  Basically,  one  may  proceed  along  the  lines  of  Fig.  3,  whereby 
changes  in  terms  of  time  must  be  taken  into  account. 


4.2  Development  of  the  Electromagnetic  Environment 

EMC,  lightning  stroke  and  NEMP  are  considered  here. 

As  far  as  EMC  is  concerned,  a  gradual  increase  in  the  electromagnetic  environment 
takes  place,  due  to  higher  transmitter  powers,  more  frequent  transmitters  and  an  expan¬ 
sion  of  the  frequency  range.  A  jump  of  at  least  3  dB  between  the  aircraft  types  under 
consideration  can  be  assumed. 

As  a  natural  phenomenon,  the  lightning  stroke  is  of  course  constant.  The  threat 
model,  however,  will  perhaps  have  to  be  adapted  in  future  to  meet  new  requirements. 

Faster  semiconductors  make  it  necessary  to  take  into  consideration  faster  lightning.  In 
the  following,  however,  lightning  will  still  be  assumed  to  be  constant  for  all  three 
types  of  aircraft. 

At  least  in  the  FRG,  NEMP  has  only  recently  entered  the  scene  as  a  threat  parame¬ 
ter.  For  new  developments,  this  could  be  related  to  the  aircraft  types,  approximately  as 
of  the  mixed  structure.  Since,  however,  NEMP  is  of  general  interest  in  connection  with 
subsequent  hardenings,  the  nuclear  pulse  is  considered  for  all  aircraft  types.  For  this 
reason.  Fig.  3  is  taken  as  a  basis  as  the  electromagnetic  environment  in  conjunction  with 
the  aircraft  types. 

Fig.  4  provides  an  overview  as  to  which  frequency  range  is  involved  with  EMC, 
lightning  and  NEMP  (powers/energies;  approx.  10  -  90  *  for  the  pulse-shaped  signals). 


4.3  Coupling  In  Via  the  Airframes 

The  fields  coupled  in  and  the  interference  signals  on  lines,  which  again  depend 
on  the  lields,  are  of  interest. 


4.3.1  Fields  Coupled  In 

Basically,  a  differentiation  can  be  made  between  two  types  of  coupling  in  ,  namely: 

the  direct  coupling  in  of  the  external  fields  (of  importance  in  connection  with 
EMC  and  NEMP). 

the  coupling  in  through  currents  on  the  structure  (of  importance  in  the  case  of 
a  direct  lightning  hit  and  the  resonant  currents  occurring  due  to  NEMP). 

A)  Coupling  In  of  the  External  Fields 

Fig.  5  shows  the  attenuation  curve  for  a  typical  aluminum  and  CFC  structure,  res¬ 
pectively. 

In  the  lower  frequency  range,  the  curve  applies  to  magnetic  fields  (electrical 
fields  are  suppressed  satisfactorily  caused  by  high  reflection  loss  in  the  case  of 
poor  conductive  materials,  such  as  CFC,  too). 

The  attenuation  is  limited  locally  as  a  result  of  apertures  which  are  leaky  in  the 
electrical  sense  (e.g.  access  doors  to  avionics).  A  mean  value  of  40  dB  is  assumed, 
which  can  be  reached  without  any  great  efforts. 


In  the  upper  frequency  range,  the  attenuation  is  decreased  due  to  aircraft  reso¬ 
nances  and  due  *-  >  resonance  effects  of  the  leaky  apertures. 

Comparing  the  curves  shows  the  following  differences  between  the  aluminum  and  CFC 
structures: 

a)  EMC 

Degradations  amounting  to  up  to  30  dB  at  frequencies  below  some  100  KHz  for  the 
CFC  structure.  In  the  case  of  a  closed  structure  (optimum  shielding),  the  differ¬ 
ence  would  be  present  at  higher  frequencies,  too. 

b)  NEMP 

As  far  as  the  direct  coupling  in  of  the  fields  is  concerned,  when  assuming  the 
40  dB  l’mit  for  an  airframe  sealed  involving  average  effort,  it  is  almost  negli¬ 
gible  as  to  whether  the  latter  is  made  of  CFC  or  of  aluminium.  -  The  difference 
for  closed  structures  would  be  considerable  (Fig.  6:  90  dB  for  A1  in  comparison 
with  21  dB  for  CFC). 

Aircraft  with  mixed  structures  behave  similarly  to  metal  aircraft.  However,  they 
certainly  feature  greater  local  field  intensity  increases  at  higher  frequencies,  too, 
when  GRP  is  used  as  the  door  material  (even  than  with  CFC). 

B)  Coupling  In  Fields  through  Currents  on  the  Structure 

This  type  of  coupling  in  is  of  importance  for  the  direct  lightning  hit  and  for 
NEMP.  The  latter  can  cause  resonance  currents  outside  on  the  structure  of  up  to 
some  KA  at  frequencies  from  10  MHz  up  to  some  10  MHz  (small  aircraft!). 

The  fields  generated  can  be  estimated  with  the  aid  of  the  simple  model  shown  in 
Fig.  7.  The  fuselage  is  approximated  by  means  of  a  cylinder  featuring  a  constant 
wall  thickness  and  an  aperture. 

The  following  fields  are  generated: 

a)  An  E-field  depending  on  the  transfer  impedance  and  on  the  current  flowing  out¬ 
side  on  the  structure. 

b)  Magnetic  fields  near  the  aperture  depending  on  the  local  current  distribution, 
and  decreasing  inside  with  the  cubic  number. 

Fig.  8  illustrates  the  typical  transfer  impedance  of  an  aircraft  fuselage  made 
of  aluminum  and  CFC. 

When  CFC  is  used,  fields  of  about  1500  V/m  (with  A1  merely:  0.2  V/m )  are  yielded 
everywhere  in  the  aircraft  fuselage  for  the  current  of  the  customarily  used 
standard  lightning  of  200  KA.  In  the  case  of  NEMP,  fields  of  approx.  10  V/m 
(CFC)  or  10-1^  V/m  (Al),  respectively,  are  generated.  -  An  aircraft  with  a  mixed 
structure  should  be  considered  in  this  case  like  a  metal  aircraft. 

Large  local  field  intensities  greater  than  the  levels  indicated  above  may  occur 
due  to  transfer  resistances  between  airframe  parts  in  the  case  of  the  metal  as 
well  as  the  CFC  structure.  Fig.  9  provides  an  idea  of  this.  In  the  event  of 
lightning,  voltage  differences  amounting  to  about  20  V  are  yielded  with  an  alu¬ 
minium  structure  and  to  approx.  0.2  V  with  NEMP.  Values  of  4000  V  (decrease  by 
flash-overs)  or  40  V,  respectively,  can  be  generated  by  the  CFC  airframe. 

In  the  case  of  fields  coupled  in  through  the  aperture,  an  attenuation  of  40dB  is 
assumed  in  accordance  with  Fig.  5.  H-fields  of  approx.  500  A/m  (lightning)  or  of 
5  A/m  (NEMP),  respectively,  are  then  yielded  for  Al  as  well  as  CFC  structures 
(equal  current  distribution)  for  a  fuselage  diameter  of  about  1.5  m.  -  Mixed 
structures  behave  similarly  to  metal  or  CFC  structures  when  CFC  is  used  to  cover 
the  aperture.  Local  field  increases  occur  in  the  case  of  GRP. 

Somewhat  different  conditions  arise  comparing  the  types  of  structures  upon  tak¬ 
ing  into  consideration  that,  in  general,  metallic  longitudinal  conductors  (e.g. 
frames,  tubes)  are  used  inside  aircraft.  This  is  not  significant  for  metal  air¬ 
frames. 

With  CFC  structures,  however,  part  of  the  currents  flowing  externally  is  concen¬ 
trated  on  these  internal  conductors.  As  a  result,  additional  magnetic  fields 
occur  everywhere  in  the  aircraft. 

Fig.  10  gives  an  idea  of  which  field  intensities  may  occur.  A  metal  conductor 
should  be  located  in  longitudinal  direction  in  the  aircraft  fuselage,  featuring 
a  cross  section  of  500  mm^  and  an  inductivity  of  approx.  0.2  uH/m. 
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After  a  lightning  stroke,  currents  up  to  30  KA  flow  on  the  internal  conductor  in 
CFC  structures.  Even  at  a  distance  of  30  cm,  these  generate  fields  of  up  to  15 
KA/m.  The  corresponding  levels  for  aluminum  structures  are  approx.  5  A  and 
2-3  A/m. 

In  the  case  of  NEMP,  the  corresponding  levels  are  small  compared  with  the  fields 
intensities  coupled  in  via  the  apertures. 

Particularly  with  CFC  structures,  the  ratios  become  even  more  unfavourable  when 
a  joint  between  the  airframe  parts  is  bridged  by  the  internal  conductor  (Fig. 

9). 

C)  Comparison  Between  Coupling  In  of  Fields  with  Respect  to  the  Different  Types  of 
Airframes 


Fig.  11  serves  to  compare  the  different  types  of  aiframes  with  respect  to  the  alu¬ 
minium  airframe. 

A  distinction  is  made  between  local  couplings  in  and  couplings  in  which  are  gene¬ 
rally  effected  over  the  entire  airframe. 

It  is  shown  that  the  mixed  structure  basically  behaves  like  the  metal  airframe,  but 
that  local  field  intensity  increases  may  occur. 

This  applies  especially  to  the  use  of  GRP  avionic  doors  or  panels. 

Relatively  large  differences  arise  with  CFC,  which  affect  the  entire  interior  of 
the  airframe. 

For  EMC  the  differences  in  the  lower  frequency  range  amount  from  0-30  dB  to  some 
100  KHz. 

For  lightning,  the  differences  would  amount  to  70  dB,  taking  the  closed  structures 
into  account.  Upon  consideration  of  the  couplings  in  through  apertures,  the  differ¬ 
ences  are  reduced  to  approx.  30  dB. 

With  NEMP,  differences  amounting  to  60  dB  (closed  structure)  or  approx.  10-20  dB, 
respectively  (apertures  taken  into  consideration),  must  be  anticipated. 


4.3.2  Coupling  into  Cables 

The  interference  signals  induced  in  the  cables  depend  on  the  existing  fields  (Sec¬ 
tion  4.3.1)  and  on  the  conductive  coupled  in  signals. 

The  differences  with  respect  to  conducting  coupling  among  the  various  types  of  air¬ 
frames  can  be  estimated  approximately  by  means  of  the  model  shown  in  Fig.  10. 

A  conductor  (e.g.  cable  shield),  which  may  feature  an  inductivity  of  1  uH  per  m,  is 
assumed  in  a  cylinder  characteristic  of  the  airframe  under  consideration.  The  ratio  be¬ 
tween  the  current  flowing  externally  over  the  airframe  and  the  current  on  the  internal 
conductor  can  be  taken  as  a  criterion  for  the  conductive  coupling. 

This  is  shown  for  a  typical  closed  CFC  and  Al  structure  in  Fig.  12.  The  relatively 
high  levels  which  are  coupled  in  the  lightning  range  with  CFC  structures  as  well  as  the 
extreme  differences  between  CFC  and  Al  airframes  are  illustrated.  Upon  considering  prac¬ 
tical  aspects,  for  instance  the  presence  of  a  joint,  the  differences  decrease.  However, 
they  still  amount  to  over  40  dB  (dashed  curves  in  Fig.  12).  This  value  is  almost  constant 
in  the  frequency  range  observed,  i.e.  it  applies  basically  to  EMC,  lightning  and  NEMP. 

Mixed  structures  behave  similarly  to  metal  structures  (slight  increase,  since  the 
impedance  between  the  airframe  parts  is  in  certain  circumstances  larger  over  the  circum¬ 
ference. 

4.3.3  Comparison  Between  Coupling  In  with  Respect  to  the  Airframes  Under  Consideration. 

The  fields  coupled  in  must  be  considered  at  this  point  in  conjunction  with  the 
signals  induced  in  the  cables. 

If  the  results  shown  in  Fig.  11  and  12  are  taken  as  a  basis,  approximately  the 
following  degradations  can  be  estimated  for  the  CFC  structure  in  comparison  with  the 
metal  structure: 

-  EMC: 

up  to  30  dB  in  the  lower  frequency  range;  no  degradation  in  the  remaining  range. 


effect  of  lightning: 
about  40  dB 


-  NEMP: 

about  20  dB. 

Mixed  structures  (use  of  GRP!)  lie  between  the  CFC  and  the  metal  structures.  Since 
they  differ  from  the  latter  above  all  due  to  locally  limited  field  intensity  increases 
they  shall  be  classified  nearer  to  the  metal  airframes.  A  difference  of  about  5  dB  is 
assumed . 

The  numerical  values  estimated  above  certainly  depend  very  considerably  on  the  res¬ 
pective  aircraft  configurations.  However,  they  do  provide  some  reference  values  for  the 
orders  of  magnitude  to  be  anticipated. 


4.4  Susceptibility  of  Electronic  Components 

The  following  were  used  in  succession  as  typical  components  in  aircraft  electro¬ 
nics:  the  tube,  the  transistor  and  the  integrated  circuit. 

The  destructive  and  interfering  energies  for  these  components  are  plotted  in 
Fig.  13.  It  is  evident  that  up  to  now  the  susceptibility  has  continued  to  increase  with 
the  advance  of  technical  developments.  A  difference  of  around  40  dB  exists  between  tube 
and  transistor,  between  transistor  and  IC  a  difference  of  about  20  dB. 

There  are  links  in  terms  of  time  between  the  components  shown  in  Fig.  13  and  the 
aircraft  structures  under  consideration. 

Although  tubes  will  still  be  met  within  modern  CFC  aircraft  and  integrated  circuits 
are  already  being  applied  in  metal  aircraft,  certain  focal  points  of  application  will 
still  remain. 

The  following  can  be  stated: 

-  metal  structures: 
tubes,  transistors 

mixed  structures: 
transistors,  IC's 

-  CFC  structures: 

IC's. 


4.5  Danger  to  the  Equipment  in  the  different  Aircraft  Structures 

It  is  possible  to  make  a  statement  on  the  danger  to  the  equipment  by  comparing  the 
electromagnetic  environment  coupled  in  with  the  existing  susceptibilities.  Fig.  14  provi¬ 
des  such  an  illustration  for  the  aircraft  structure  under  consideration. 

The  interferences  coupled  in  are  broken  down  respectively  into  EMC,  lightning  and 
NEMP.  The  explanations  in  Section  4.3  were  taken  as  a  basis  for  coupling  in,  and  Fig.  3 
for  the  development  of  the  electromagnetic  environment. 

Fig.  14  shows  the  following: 

In  general,  the  problems  which  are  to  be  solved  in  connection  with  the  "electro¬ 
magnetic  effects"  increase  tremendously  as  time  goes  on  and  technology  advances. 

Problems  concerning  lightning  protection  become  particularly  extensive.  In  com¬ 
parison  with  metal  aircraft  featuring  tubes,  they  increase  by  the  factor  of 
approx.  10^®  in  the  case  of  modern  CFC  aircraft  featuring  IC's.  -  The  same  ap¬ 
plies  to  a  somewhat  lesser  extent  to  NEMP. 

-  The  problem  relating  to  EMC  appear  to  increase  less  strongly,  with  the  exception 
of  the  lower  frequency  range,  whicn  is  not  usually  of  any  great  significance. 
What  must  be  taken  into  consideration  in  this  context,  however,  is  that  aircraft 
are  becoming  dependend  to  an  ever  greater  degree  on  the  electronics,  i.e.  more 
and  more  equipment  is  becoming  critical  with  respect  to  safety.  This,  however, 
requires  safety  margins  of  20  dB  instead  of  6  dB.  All  in  all,  differences  of 
more  than  20  dB  are  the  case  here  (comparing  metal  with  CFC  aircraft). 

The  transition  from  previously  used  metal  and  mixed  structures  to  CFC  airframes 
entails  problems  relating  to  lightning  protection,  EMC  as  well  as  NEMP  hardening 
which  are  almost  as  extensive  as  those  encountered  earlier  with  metal  aircraft 
upon  transition  from  tube  to  semiconductor  technology. 


5.  POSSIBLE  SOLUTION  TO  THE  PROBLEMS 

The  details  given  in  the  previous  section  showed  that  considerable  problems  remain 
to  be  solved  in  connection  with  lightning  protection,  NEMP  hardening  and  EMC,  in  parti¬ 
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cular  as  far  as  the  transition  to  CFC  construction  is  concerned.  This,  however,  is  just 
the  step  which  is  currently  being  undertaken  in  aircraft  development.  The  existing  ranu- 
als  ar.d  specifications  can  only  be  used  to  solve  the  problems  to  a  limited  extent,  since 
the  know-how  defined  therein  is  based  on  metal  aircraft.  Some  thoughts  concerning  possib¬ 
le  additional  requirements  and  changes  are  compiled  in  the  following  section.  However,  a 
great  number  of  experimental  and  theoretical  investigations  must  be  carried  out  before 
reliable  and  optimum  solutions  can  be  drawn  up.  However,  the  problems  can  be  solved. 

Fig.  15  provides  a  survey  of  the  measures  which  appear  to  be  necessary.  They  extend 
from  the  airframe  level  over  the  cabling  and  ground  concept  up  to  more  stringent  equip¬ 
ment  requirements  and  additional  tests  at  system  level. 

A)  Airframe/Structure 

This  must  be  designed  so  as  to  be  as  leak-proof  as  possible  from  the  electrical 
point  of  view,  in  order  to  achieve  on  the  one  hand  good  shielding  attenuation  and 
on  the  other  hand  low  voltage  drops.  The  electrical  sealing  of  access  doors  etc.  as 
well  as  the  creation  of  low-resistance  transfer  resistances  between  airframe  parts 
are  of  particular  interest. 

Metallizing  CFC  structural  parts  does  appear  helpful  but  not  absolutely  necessary 
for  electrical  reasons.  If  this  is  necessitated  for  lightning  protection,  for  in¬ 
stance,  it  should  be  incorporated  in  the  shielding  concept. 

B)  Cabling  and  Grounding  Concept 

In  addition  to  the  greater  attention  to  be  paid  to  the  customary  EMC  guidelines, 
the  following  items  are  of  especial  interest: 

a)  absolute  both-end  grounding  of  the  cable  shields 

b)  avoidance  at  all  costs  of  pig-tail  grounding.  In  particular  with  NEMP  (resonance 
currents  on  the  aircraft  structure!)  as  well  as  with  EMC,  degradations  amounting 
up  to  40  dB  can  be  expected  for  average  cable  lengths  and  single  braid  shields 
(Fig.  16).  This  means  that  the  104-fold  interference  power  is  coupled  in. 

c)  control  of  other  possible  leakage  places  in  the  shielded  circuit.  If  the  shield¬ 
ing  has  been  grounded  properly,  other  electrical  leakage  places  become  increas¬ 
ingly  predominant.  This  applies  especially  in  connection  with  lightning  protect¬ 
ion  and  NEMP  hardening.  Transfer  resistances  between  connectors,  connectors  and 
cases  and  case  sections  are  of  importance  (Fig.  17). 

d)  Routing  of  the  Cables 

In  view  of  the  increasing  effect  of  external  interferences,  the  cabling  concept 
must  in  certain  circumstances  be  conceived  a  new  (Fig.  18).  The  internal  compa¬ 
tibility  was  cf  primary  interest  for  metal  aircraft.  This  meant  laying  the  cab¬ 
les  of  the  different  EMC  categories  as  far  apart  as  possible  (to  prevent  cross 
coupling!).  In  the  case  of  pure  CFC  structures,  the  magnetic  fields  caused  by 
external  sources  of  interference  (lightning,  NEMP)  could  certainly  be  of  greater 
significance.  Laying  all  three  EMC  categories  in  one  bundle  of  cables  would  then 
be  more  favourable  (prevention  of  loops!). 

e)  Grounding  Concept 

The  grounding  concept  is  of  great  importance  when  interference  signals  are  coup¬ 
led  in  (Fig.  19).  This  applies  in  particular  to  t.he  low-frequency  range,  i.e.  in 
connection  with  lightning  protection.  Depending  on  the  grounding,  the  differen¬ 
ces  may  amount  to  100  dB.  Greater  control  of  input  filters  and  capacities  ap¬ 
pears  necessary  in  this  context,  too,  since  the  ground  conditions  can  also  be 
impaired  by  the  latter. 

C)  Equipment 

It  is  important  to  know  whether,  for  instance,  more  stringent  requirements  should 
be  stipulated  for  each  piece  of  equipment  or  whether,  for  instance,  the  introduc¬ 
tion  of  shielded  compartments  is  preferable  (Fig.  20).  This  would  probably  permit 
the  use  of  electronics  tested  according  to  previously  customary  standards.  One  pro¬ 
blem  in  connection  with  the  equipment  might  in  certain  circumstances  relate  to  the 
coupling  of  circuits  via  the  inside  of  the  equipment,  e.g.  between  non-critical 
circuits  on  which  relatively  high  interference  levels  are  permissible,  and  ones 
which  are  critical  with  respect  to  safety  (Fig..  21). 

D)  Use  of  new  techniques 


Especially  in  connection  with  CFC  structures  the  use  of  optical  links  seems  to  be 
very  helpful.  Almost  all  EMC-,  lightning-  and  HEMP'  problems  can  be  avoided. 
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E)  Additional  Tests  at  System  Level 

These  are  necessary,  since  compatibility  with  the  interference  effects. 

-  will  be  ensured  more  and  more  by  means  of  measures  at  system  level 

-  any  interferences  which  may  occur  jeopardize  the  safety  of  the  aircraft  to  an 
incrasing  degree. 

Comprehensive  test  set-ups  have  already  been  developed  for  NEMP  hardening.  This  is 
just  at  the  starting  point  as  far  as  lightning  protection  is  concerned.  This  is 
limited  with  regard  to  EMC  above  all  to  verification  of  the  internal  compatibility. 
Compatibility  with  the  environment  is  hardly  taken  into  account.  For  this  reason, 
the  introduction  of  appropriate  requirements  and  standardised  procedures  appears  to 
be  necessary  above  all  for  lightning  protection  and  external  EMC. 

6.  Conclusion 


The  above  statements  have  shown  that,  as  technical  progress  is  made,  the  problems 
concerning  electromagnetic  effects  in  aircraft  construction  become  increasingly  difficult 
to  solve.  This  is  primarily  due  to  the  increasing  susceptibility  of  the  electronic  compo¬ 
nents  and  to  the  more  unfavourable  coupling-in  conditions  with  modern  structures.  This 
has  become  a  perticularly  large  step  upon  the  introduction  of  CFC  construction.  In  gene¬ 
ral  it  can  be  said  that  far  more  care  must  be  paid  to  obeserving  the  appropriate  design 
guidelines  in  order  to  be  able  to  solve  the  pertinent  problems.  In  part,  however,  some 
thought  must  be  paid  as  to  whether  previously  applicable  principles  should  be  subject  to 
revision  as  well.  However,  the  problems  can  be  solved. 
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FIG  3:  DEVELOPMENT  OF  ELECTROMAGNETIC 
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FIG  4:  MAIN  FREQUENCY  RANGES  OF  THE 
ELECTROMAGNETIC  EFFECTS 
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FIG  5 :  SHIELDING  OF  TYPICAL  STRUCTURES 
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FIG 8 : TRANSFERIMPEDANCE  OF  TYPICAL  FUSELAGES 


FIG  9:  IMPEDANCE  OF  TYPICAL  JOINTS  AROUND 
THE  FUSELAGE 
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FIG  10:  INSIDE  CURRENTS  AND  INSIDE  FIELDS 
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FIG  1 1 :  INSIDE  FIELDS  RELATED  TO  METALLIC 
STRUCTURE 


FIG  12:  CONDUCTIVE  COUPLING  INTO  CABLES 


FIG  13:  SUSCEPTIBILITY  OF  TYPICAL  ELECTRONIC 
COMPONENTS 


FIG  14: INCREASING  DIFFERENCE  BETW.  COUPLED-IN 
SIGNALS  AND  EXISTING  SUSCEPTIBILITIES 
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BETTER  INTEGRATION  OF  STRUCTURE  INTO  EMC-DESIGN 

-  GOOD  SHIELDING 

-  LOW- RES  I  ST.  JOINTS 

MORE  CAREFUL  CONTROL  OF  CABLING  AND  GROUNDING 

USUAL  EMC-DESIGN; OF  SPECIAL  INTEREST: 

-  BOTH  END  GROUNDING  OF  CABLE  SHIELDS 

-  NO  PIG-TAIL  GROUNDING  OF  SHIELDS  (FIG. 16) 

-  CONTROL  OF  OTHER  LEAKAGES  IN  THE  SHIELDED  CIRCUIT  (FIG. 17) 

-  OTHER  CABLE  ROUTING  PHILOSOPHY?  (FIG. 18) 

-  CAREFUL  GROUNDING  CONCEPT!  (FIG. 19) 

ADDITIONAL  REQUIREMENTS  ON  EQUIPMENT  LEVEL 

-  HIGHER  REQUIREMENTS  FOR  EQUIPMENT  OR  INSTALLATION  OF 
SHIELDED  COMPARTMENTS? ( F I G . 20 ) 

-  CONTROL  OF  COUPLING  VIA  EQU I PMENT? ( F I G . 21 ) 

additional  tests  on  system  level 

-  NEMP  :  IN  USE 

-  LIGHTNING  :  IN  BEGINNING 

-  EMC  :  INTERNAL  EMC;N0  STANDARD  ENVIRONMENT  TESTS 

FIG  15:  SURVEY  OF  IMPROVEMENTS 


FIG  1 6 :  ADDITIONAL  COUPLING  OF  A  PIG-TAIL 
GROUNDED  SHIELD 
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FIG  17:CONSIDERATION  OF  ADDITIONAL  LEAKAGES 
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FIG  18:  OTHER  PHILOSOPHY  OF  CABLE  ROUTING  ? 
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FIG  19: SIGNIFICANCE  OF  SIGNAL  GROUNDING  CONCEPT 
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FIG  20:  CONCENTRATION  OF  EQUIPMENT  IN 
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FIG  2 1 :  COUPLING  BETWEEN  DIFFERENT  CLASSES  OF 
SIGNALS  VIA  EQUIPMENT  ? 
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DISCUSSION 


W.RJohnson,  US 

( 1 )  Did  you  determine  the  difference  in  shielding  effectiveness  between  aluminum  and  CFC  by  mathematical 
calculations  or  by  tests? 

(2)  What  test  method(s)  did  you  use? 

Author’s  Reply 

( 1 )  Both  curves,  that  means  for  aluminum  and  carbon  fiber,  have  been  calculated,  but  the  results  for  carbon  fiber 
have  been  controlled  by  measurements. 

(2)  The  method  of  MIL-STD-285  has  been  used  to  measure  the  attenuation  of  the  carbon  fiber  material. 
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AVIONICS/ CREW  STATION  INTEGRATION 


William  G.  Mullay 
Project  Director 


Naval  Air  Developaent  Center 
Warainater,  Pennsylvania  18974 
United  States  of  America 


SUMMARY 


'  The  U.S.  Navy  haa  been  ancouraging  advanced  developaent  concepts  aiaed  at  increasing  tha  aircraft 
instruaentation  performance  for  mlti-platform  applications  of  1990's  weapons  systema. The  thraa  areas 
covered  by  tha  Navy's  rasearch  and  development  effort  are  System  Integration,  Technology,  and  Human  Factors. 
Tha  objectives  of  these  threa  areas  are  as  follows: 

- -  ~  - 

je  \Tha  System  Integrationjpbj actives  are  to  produce  a  system  architecture  easily  adaptable  to  many 
platforms.  ... 


Technology  objectivas  are  to  determine  the  state  of  the  art  for  displays,  electronics,  and  controls. 


a  Cfha  Human  Factors  objectives  are  to  determine  tha  proper  human-machlna  interfaces  so  that  tha 
ultimata  crew  station  will  be  capable  of  providing  the  pilot  with  tha  proper  display  and  controls 
performance  to  satisfy  tha  diverse  requirements  of  Jr  fighter,  attack,  ASW,  fixed-wing,  rotary- 
wing,  and  V/STOL  platforms  in  both  a  one-man  crev  or  two-man  crew  matrix. 


All  data/control  interfaces  among  units  of  this  crew  station  system  and  other  platform  subsystems 
will  be  via  digital  data  buses  and  video  multiplex  buses.  No  individual  discrete  signal,  data,  or  control 
linas  will  be  naeded.  This  paper  discusses  tha  six  interfaces  necessary  to  ensura  tha  optimum  development 
of  this  crew  station,  tha  predicted  platform  mission  lmprovamants,  and  the  requisite  life-cycle  cost  con¬ 
siderations.  This  concept  will  serve  as  a  basis  for  planning  the  integration  of  tha  necessary  hardware 
and  software  features  in  currant  and  future  weapons  systems. 


BACKGROUND 


The  requirement  for  a  significantly  Improved  approach  to  aircraft  cockpit  instrumentation  and  controls 
arises  from  tha  basic  naad  for  improved  military  effactlvenass  against  all  existing  and  plannad  piloted 
weapon  systems.  Increased  effectiveness  is  needed  to  countar  the  threat  posed  by  potentially  hostile 
forces  whila  accomplishing  this  goal  within  the  bounds  set  by  present  constraints  on  essential  resources. 


U.S.  Naval  Air  Forces  will  continue  to  ba  faced  with  a  constantly  escalating  threat  to  thalr  ability 
to  maintain  air  superiority  and  sea  control  on  a  global  basis,  24  hours  a  day  and  undar  Instrument  meteor¬ 
ological  conditions  -  Instrument  flight  rules  (IMC-IFR). 


As  weapon  system  performance  parltias  among  competing  force  structures  are  achlaved,  as  the  life-cycle 
cost  of  operational  equipment  continues  to  increase,  and  aa  tha  sophistication  of  both  the  equipment  and 
its  required  Naval  air  mission  continues  to  grow,  tha  graater  becomes  the  importance  of  the  human-machine 
interface  in  exploiting  tha  maximum  capabilities  of  tha  piloted  aircraft. 


Now,  a  need  exists  for  a  totally  new  approach  to  cockpit  instrumentation  and  controls.  In  response 
to  this  naad,  the  Naval  Air  Systems  Command  initiated  devalopment  af forts  on  the  Advanced  Integrated  Display 
System  (AIDS)  as  tha  most  feasible  approach  to  meeting  ths  demands  of  tha  1990' s  weapons  systams. 


The  AIDS  will  provide  weapons  systems  lmprovamants  in  the  following  three  general  areas  of  effectlve- 
nass,  adaptability  and  support ability. 


Effactiveness 


e  Tha  tactical  posture  of  the  pilot  will  be  Improved  in  two  ways:  (1)  there  will  be  more  time  to 
asseaa  a  situation  end  make  a  dacislon  through  reduced  visual  scan  time  as  compared  to  dlacrets 
instrumentation,  and  (2)  there  will  be  improved  contact  with  the  world  "outside  ths  cockpit"  under 
all-wee ths r  conditions  with  tactical  problems  overlaid  on  sutosstsd  situation  displays. 


a  Aircraft  availability  will  ba  improved  through  functional  redundancy  in  display  systams  and 
through  ranking  of  failure  modes  to  distinguish  batwssn  critical  and  non-critical  situations. 


Adaptability 


e  Ths  modular  nature  of  AID6  provides  a  building  block  capability  that  allows  application  of  tha 
complate  system  or  its  components  in  new  or  existing  aircrsft. 


e  Whila  tha  moat  prassing  need  is  seen  aa  the  aingle-placo  combat  platform,  both  the  technology  and 
components  ara  suited  to  the  multi-manned  aircraft  as  well. 


e  AIDS  will  employ  technology  that  ia  similar  to  or  caapatibla  with  sensor  system  dsvalopments 
likely  to  be  in  use  over  an  extended  period  of  time. 
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Supportablllty 

•  AIDS  will  reduce  the  number  of  individual  types  of  these  equipments  in  the  Naval  inventory. 

•  AIDS  will  reduce  the  number  of  individual  skills  now  required  to  maintain  aircraft  instrument/display 
systems. 

•  AIDS  will  reduce  training  time  requirements  in  each  area  for  both  pilots  and  maintenance  personnel. 

•  AIDS  will  reduce  downtime  through  maximum  use  of  solid-state  components  and  integrated  circuitry 
that  is  compatible  with  built-in  test  (BIT)  and  automatic  test  equipment  (ATE). 

WEAPON  SYSTEM  COSTS 

A  major  factor  in  the  acquisition  of  any  modern  military  system,  particularly  a  weapons  system,  is 
the  planning,  control,  and  minimization  of  system  life-cycle  costs.  These  costs  accrue  from  initial  develop¬ 
ment  and  acquisition  of  a  weapons  system,  and  continue  through  the  operational  and  support  phases  of  the 
system.  Costs  of  system  operations  must  include  training  of  operational  and  maintenance  personnel,  opera¬ 
tional  software  development,  and  the  development  of  adequate  operational,  intermediate,  and  depot  level 
maintenance  documentation.  The  elements  of  Integrated  Logistics  Support  (ILS)  come  into  play  to  ensure 
optimum  support  of  the  operational  weapons  systems  throughout  their  life  cycle. 

With  these  points  in  mind,  let  us  look  at  the  various  elements  to  be  considered  in  the  life-cycle 
cost  planning  of  a  crew  station. 


SYSTEMS  DEVELOPMENT  COSTS 

The  systems  of  the  future  must  be  capable  of  being  assembled,  much  like  the  "Tinker  Toys"  we  played 
with  as  a  child.  The  hardware,  software  and  Interfaces  must  be  so  designed  that  they  can  be  assembled, 
integrated  and  tested  by  medium-skilled  personnel  in  a  reasonably  short  (therefore  less  costly)  period  of 
time.  The  hardware  and  software  must  be  so  simple  and  so  transparent  to  the  technology  that  the  interfacing 
of  these  hardware  and  software  modules  present  only  a  minimal  task. 

Hardware  Development 


Programs  such  as  the  U.S.  Air  Force  Digital  Avionics  Information  Systems  (DAIS)  and  the  U.S.  Navy 
Advanced  Integrated  Display  System  (AIDS)  have  developed  hardware  that  can  be  used  as  prototypes  for 
interchangeable  modules  in  future  aircraft  and  retrofit  of  existing  weapons  systems.  The  components  of 
These  systems  are  shown  in  Figure  1.  Both  programs  are  proving  that  modular  concepts  in  hardware  develop¬ 
ment  are  possible.  Again,  the  technical  problems  are  surmountable  while  the  financial  roadblocks  are 
proving  not  to  be.  These  modules,  like  any  new  model,  have  higher  initial  costs.  The  life-cycle  costs, 
where  the  real  savings  will  be,  are  not  being  taken  into  account  because  of  today’s  fiscal  limitations. 

Software  Development 


Today,  for  a  data  processing  system,  80  per  cent  of  the  total  cost  is  for  software.  This  software 
percentage  is  expected  to  increase  by  1985  so  that  90  per  cent  of  the  systems  costs  will  be  for  the  software. 

Military  Higher-Order  Languages  (HOL’s)  such  as  ADA  (DoD),  JOVIAL  (USAF),  and  CMS-2  (USN),  have  been 
developed  for  the  large  quantity,  high-speed  computations  associated  with  sensor  signal  processing.  However, 
not  enough  attention  is  being  paid  to  real-time  interactive  graphics  requirements  needed  for  today’s  system, 
much  less  the  larger  demands  predicted  for  the  future  for  large-scale  computer  graphics  in  real  time. 


SOFTWARE 


Figure  1.  Displays  and  Control  Interfaces 
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The  languages  oust  allow  a  non-programmer  of  the  future  to  interact  with  these  new  systems  so  that 
medium-trained  personnel  can  develop  and  evaluate  new  and  innovative  concepts  in  system  operability. 
This  should  allow  for  more  acceptability  due  to  the  adaptation,  more  quickly  that  realizable  today,  to 
the  chsnging  mission  requirements  and  changing  tactics. 

Interface  Development 

The  interface  area  is  receiving  more  and  more  attention  through  the  expanding  use  of  MIL-STD-1553B. 
This  expanding  use  is  experiencing  growing  pains,  as  any  new  concepts  do,  but  the  development  bugs  are 
being  Ironed  out.  However,  there  are  three  problem  areas  that  deserve  Increased  attention. 

First,  the  military  with  their  1553B,  and  the  commercial  airlines  with  the  ARINC  429,  are  developing 
incompatible  systems.  Therefore,  cost  savings  derived  from  large-quantity  productions  are  going  to  be 
lost  to  the  military  since  their  share  of  the  market  is  diminishing. 

Second,  there  is  the  requirement  for  transmission  of  information  at  a  higher  rate  than  one  megabit 
(1553B  limit).  This  has  been  recognized  and  an  analysis  is  being  conducted  of  today's  and  future  require¬ 
ments  for  high-speed  digital  transmissions. 

Third,  there  is  the  requirement,  unique  to  the  crew  station  community,  for  the  transmission  of  video 
information.  The  AIDS  has  developed  a  video  bus,  very  similar  to  a  cable  TV  system,  that  will  facilitate 
the  initial  development  and  future  modification  of  integrated  multi-function  displays.  The  video  bus 
utilizes  standard  composite  TV  for  two  important  reasons;  it  is  readily  available  and  compatible  equipment 
is  very  reasonable  in  cost.  This  is  fine  for  525-line  monochrome  systems.  We  are  attempting  to  define 
what  should  be  done  for  a  color  system  and  higher  line  rates  such  as  875  and  1024.  The  NTSC  Color  standard 
is  not  acceptable  for  small  symbology.  An  R-G-B  type  of  Interface  is  some  Improvement,  but  requires  too 
much  bandwidth.  This  area  requires  much  more  effort  than  it  is  presently  receiving. 

PRODUCTION  COSTS 


The  production  of  these  systems  must  be  kept  in  mind  during  the  development  phase.  The  electronics 
technology  has  made  such  tremendous  strides  with  LSI  and  VLSI  that  other  technologies  have  been  left  in 
the  dust.  Recent  advancements  in  optics,  such  as  fiber  optics  and  diffraction  optics,  may  make  this  expen¬ 
sive  technology  more  reasonable  in  the  future.  But  other  areas,  such  as  flat  panels,  must  be  producible 
on  a  large  scale  with  automation  maximized. 


OPERATIONAL  COSTS 


Operational  costs  are  directly  relatable  to  operational  complexity.  Therefore,  the  primary  goals  in 
effective  weapons  systems  operation  should  be  to  make  the  human-machine  interface  so  easy  to  operate  that 
operator  training  and  proficiency  update  requirements  would  become  almost  negligible.  This  can  be  achieved 
by  making  the  machine  as  adaptive  as  possible  to  stimulate  the  natural  senses  of  the  human.  Long-term 
cost  savings  could  be  attained,  not  only  In  training  and  proficiency  (in  both  simulator  and  flight  time) 
costs,  but  though  reducing  loss  of  equipment  due  to  "operator  error." 

If  we  think  of  the  human-machine  interface  simply  as  communication  between  the  operator  and  the  machine, 
then  perhaps  an  analogy  can  be  drawn  to  communication  between  one  person  and  another  person. 

The  person-to-person  intercommuncations  uses  visual  (alphanumeric,  graphic  and  pictorial),  auditory 
(speech)  and  motion.  Therefore,  if  we  are  to  make  the  person-to-machine  communications  as  effective  as 
person-to-person  communications,  we  must  have: 

1.  Printed  information 

2.  Graphical  information 

3.  Pictorial  information 

4.  Two-way  verbal  communications 

5.  Motion  and  position  sensing. 

Assuming  again  that  the  closer  we  approach  person-to-person  communication,  the  better,  then,  the 
graphical  and  pictorial  information  must  be,  in  both  2D  and  3D  and  with  all  information  in  full  color. 
The  system  must  be  reactive  to  the  individual  operator  and  must  be  tailored  to  his  specific  needs,  both 
normal  and  abnormal.  The  Mark  I  individuals,  with  whoa  we  must  operate,  are  all  different.  To  expect 
all  individuals  to  fit  one  mold  is  nice  in  theory,  but  impossible  in  reality. 

The  systems  of  the  future  will  have  the  capability  for  programmed  "level-of-acceptable  performance" 
defined  for  every  Important  task  of  every  mission  mode.  The  system  can  evaluate  the  operator's  performance 
and,  if  it  falls  below  this  level,  it  will  take  over  more  and  more  of  the  functions  until  the  operator's 
performance  is  back  to  an  acceptable  level.  As  the  performance  exceeds  this  level  by  a  specified  amount, 
the  system  offers  to  give  back  to  the  operator  some  of  the  functions,  if  he  wants  them.  This  level  of 
performance  may  be  raised,  from  some  specified  lower  limit,  by  the  operator  as  he  undergoes  his  training. 
This  would  allow  the  operator  to  decide  how  many  functions  and  in  what  priority  he  wishes  to  transfer  the 
the  system.  Of  course,  this  delta  can  be  modified  up  or  down  (to  the  lower  limit)  throughout  the  operator's 
experience.  The  term  "operator"  is  used  here  because  performance  is  applicable  not  only  to  the  pilot,  but 
could  be  implemented  for  navigators,  sensor  station  operators,  tactical  officers,  etc. 

Also  during  training,  the  operator  can  have  some  freedom  in  selecting  the  type  of  information  that  is 
presented  to  him  during  the  various  mission  modes,  as  well  as  the  response  of  the  system  to  his  commands. 
This  will  allow  the  "picture  person"  and  the  "word  person"  to  tailor  the  system  to  his  Individualized 
tastes,  thereby  improving  acceptability,  Improving  operability,  and  reducing  life-cycle  costs. 
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This  natural  system  can  almost  certainly  Include  voice  communication,  meaning  voice  recognition 
(phrases  first,  then  continuous  speech)  and  voice  synthesis  (completely  synthetic  or  reconstructed  digitally 
stored  voice).  The  Helmet  Mounted  Display  (HMD)  will  be  capable  of  taking  over  an  increasingly  larger 
and  larger  amount  of  the  information  presentation  until  It  is  the  only  display  in  the  crew  station.  The 
Instrument  panel  will  be  black  and  a  synthetic  Instrument  panel  will  be  generated  on  the  HMD  when  the 
operator  looks  In  that  direction.  Eventually,  that  requirement  will  be  deleted  and  the  operator  will  keep 
his  head  and  eyes  out  of  the  crew  station  at  all  times.  The  HMD  evolution  will  be  monocular,  biocular 
and  then  binocular,  starting  in  monochrome  and  eventually  evolving  to  color  because,  as  stated  earlier, 
seeing  Images  in  color  and  3D  are  the  natural  way  of  viewing  the  real  world. 

Multifunction  controls  are  becoming  increasingly  accepted.  They  have  the  capability  of  being  introduced 
Into  the  consoles  initially  and  finally  right  into  the  armrests  of  the  seat.  Feedback  systems  to  the  HMD 
will  tell  the  operator  which  switch  his  finger  is  on  before  he  presses  the  button  so  that  he  will  not  have 
to  bring  his  eyes  back  into  the  crew  station  to  view  the  multifunction  controls.  The  multifunction  controls 
and  voice  recognition  will  probably  become  so  intertwined  that  each  will  be  a  primary  mode  of  input  for 
some  individuals  while  the  other  will  be  back-up. 

All  of  these  increases  in  capability  will  be  reflected  In  reduced  operational  costs,  due  mainly  to 
training  time  reductions  and  decreased  loss  of  equipment  due  to  "operator  error". 


SUPPORT  COSTS 


System  life-cycle  costs  can  be  further  reduced  and  controlled  through  effective  planning  of  the  Inte¬ 
grated  Logistics  Support  (ILS)  and  system  reliability  and  maintainability  (R&M). 

The  necessary  steps  to  solving  maintenance  problems  include  the  following: 

1.  Recognizing  a  malfunction 

2.  Isolating  the  malfunction 

3.  Correcting  the  malfunction 

4.  Verifying  the  correction 

3.  Documenting  the  maintenance  action 

The  AIDS  Program  Includes  the  following  equipment  at  the  crew  station: 


AIDS  Equipment 
Displays 

Multifunction  Controls 

Briefing  Information  Entry 
Devi ce 

Maintenance  Recorder 


Common  Name 
CRT 

Keyboard 
Tape  Drive 

Printer 


If  one  looks  at  the  list  on  the  right.  It  Is  not  hard  to  call  the  crew  station  a  computer  terminal 
station.  Thus,  the  crew  station  can  now  become  the  maintenance  shop  for  all  the  hardware  in  that  particular 
aircraft.  Available  are  most  of  the  necessary  tools  (BIT,  diagnostics,  instructions,  etc.)  to  be  used  by 
the  maintenance  person  to  perform  on-line  tests  to  effect  all  of  the  remedial  maintenance  required,  thereby 
reducing  system  down  time  and,  consequently,  costs. 

Imagine  the  following  scenario: 

Our  maintenance  section  la  requested  to  ensure  that  10  to  15  F-25's,  that  have  just  landed,  will  be 
ready  for  this  afternoon's  mission. 

Joe  Average  and  his  counterparts  are  assigned  to  report  upon  the  status  of  each  aircraft.  Joe  goes 
to  BUNO  17369  and,  without  need  of  electrical  power,  reads  the  printout  from  the  crew  station  printer  to 
hla  supervisor  over  a  portable  communication  link.  (The  printer  had  developed  two  copies  of  the  report 
upon  landing,  listing  all  malfunctions,  when  they  occurred.  If  they  are  intermittent,  and  what  was  the 
last  status  of  the  malfunctioning  equipment.  The  pilot  tore  off  one  copy  to  be  submitted  during  his 
debriefing,  leaving  the  other  copy  In  the  crew  station  for  the  maintenance  personnel.)  The  maintenance 
supervisor  Informs  Joe  that  this  aircraft  Is  needed  and  that  Joe  should  be  able  to  correct  these  malfunc¬ 
tions  In  time  for  this  afternoon'r  flight. 

Beside  each  malfunction  on  the  printout  Is  a  number  that  coincides  with  the  number  of  the  digital 
csssette  containing  the  diagnostic  software  for  that  problem.  Joe  selects  the  cassette  from  the  container 
he  carries  with  him.  Inserting  the  cassette  Into  the  Tape  Drive  will  run  a  diagnostic  program  and,  on 
the  CRT,  display  the  corrective  action  required.  Questions  can  be  asked  by  Joe  if  he  is  not  sure  of  what 
steps  he  must  take.  In  rsply,  he  might  receive  the  following  instructions: 

1.  Co  to  Avionics  Bay  1  (front-left) 

2.  Third  ahelf  from  top 
Replace  14th  module  from  the  right  (MODULE  743) 


3. 
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4.  Tools  needed 

•  Cross-point  screwdriver 

•  Cutting  pliers 

•  Needle-nose  pliers 

After  Joe  Is  convinced  that  he  understands  the  operations,  he  requests  a  chit  for  Module  743.  The 

printer  then  prints  the  chit  for  him  as  well  as  the  list  of  tools  required. 

After  Joe  has  submitted  the  chit  and  received  Module  743  and  the  tools  from  supply,  he  goes  to  Avionics 
Bay  1  in  the  aircraft  and  plugs  his  helmet  connection  into  shelf  number  three.  Information  is  presented 

on  the  visor  of  his  helmet  and  over  his  earphones  that  he  Is  Indeed  in  Avionics  Bay  I  and  is  at  the  third 

shelf  from  the  top.  (Or,  if  he  is  at  the  wrong  location,  he  will  be  Informed  that  he  has  made  a  mistake 
and  is  in,  for  example.  Bay  5,  the  second  shelf.)  The  removal  of  the  ) 4th  module  from  the  right  Is  also 
verified  (or  not,  if  he  is  wrong).  The  replacement  of  this  module  initiates  the  rerunning  of  the  diagnostic 
program  and  tells  him  that  he  has  indeed  corrected  the  malfunction.  He  requests  a  printout  of  the  main¬ 
tenance  action  and  receives  a  printout  of  the  corrective  actions  taken,  as  well  as  the  time  taken  to  correct 

the  malfunction.  This  printout  will  be  turned  in  to  his  maintenance  supervisor  for  inclusion  in  the  next 
maintenance  report. 

Joe  had  to  do  minimal  reading.  He  had  a  chance  to  assure  himself  of  the  steps  he  was  going  to  take, 
before  he  started,  by  requesting  information  from  an  impersonal  machine.  He  was  reassured  along  the  way 
that  he  was  correct,  step  by  step.  He  was  congratulated  in  the  end  for  a  job  well  done  and,  most  importantly, 

he  personally  did  not  have  to  fill  out  one  form,  yet  all  the  required  forms  were  filled  out  correctly.  This 

Improved  maintenance  action  will  result  in  Improved  logistics. 

Had  this  been  a  LAMPS  helicopter  or  a  VSTOL  aircraft  operating  from  a  destroyer,  the  cockpit  may  have 
been  the  only  space  available  for  any  maintenance  investigation  aboard  the  ship. 

INTERFACES 

Figure  1  portrays  the  six  Interfaces  that  must  be  controlled  for  effective  crew  station  design. 
These  interfaces  are  as  follows: 

1.  External  Bus  (X-Bus) 

The  X-Bus  proposed  for  transmission  of  digital  data  from  aircraft  sensors  and  computers  to  the 
avionics  bay  display  electronics  would  be  a  serial  digital  bus  that  would  conform  to  MIL-STD-1553B. 
A  pair  of  buses  would  be  required  to  provide  redundancy. 

2.  Avionics  Bay  Bus  (AB-Bus) 

The  AB-Bus  proposed  for  transfer  of  dlgltsl  data  between  various  uRer  elements  Installed  in  the 
aircraft  avionics  bay  such  aa  Digital  Processor,  Mass  Memory,  Raster  Symbol  Generator,  X-Bus  Interface 
and  l-Bua  Interface  would  require  a  high-speed,  16-bit,  parallel,  digital  bus. 

The  basic  purpose  of  the  AB-Bua  la  to  transfer  data  from  one  user  element  to  another  in  a  distributed 
processor  system.  The  AB-Bus  has  a  number  of  Input  'and  output  Interrupts  corresponding  to  the  number 
of  elements  connected  to  the  bus.  Each  element  on  the  bus,  when  selected,  has  a  512-k  word  address 
capability  and  communicates  with  the  bus  controller  over  a  pair  of  Input  and  output  Interrupts.  The 
Input  Interrupts  are  used  for  user  element  communications  to  the  AB-Bus  Controller  and  output  Interrupts 
are  used  for  AB-Bus  controller  to  the  user  element. 

3.  Internal  Bus  (I-Bus) 

The  I-Bus  proposed  for  transmission  of  digital  data  from  the  aircraft  avionics  bay  to  the  crew 
atctlon  displays  and  controls  would  also  be  a  serial  digital  bus  that  would  conform  to  the  MIL-STD- 
1553B.  As  for  the  X-Bus,  the  I-Bus  will  consist  of  a  pair  of  buses.  However,  both  I-buses  could  be 
In  uae  full  time.  Then  the  unlikely  failure  of  one  bus  would  require  the  reconfiguration  of  the  re¬ 
maining  bus  to  operate  on  a  degraded  mode.  The  system  would  be  designed  so  that  the  bus  controller 
would  monitor  the  bus  and,  when  it  detects  a  failure,  would  automatically  Institute  a  bus  reconfigur¬ 
ation  according  to  a  set  of  predefined  priorities. 

4.  Video  Bus  (V-Bua) 

The  V-Bus,  through  the  use  of  a  video  multiplexing  system,  will  distribute  several  video  and  sync 
signals  among  multiple  display  terminals.  This  type  of  video  signal  distribution  is  similar  to  that 
used  In  commercial  cable  television.  The  V-Bus  permits  signals  from  multiple  sources  to  be  carried  on 
one  bus  for  display  at  selected  moments  on  any  number  of  crew  station  displays.  The  ability  to  transmit 
multiple  video  signals  enables  the  sources  of  the  signal  as  well  as  display  units  to  be  changed  or  new 
ones  to  be  added  without  requiring  major  rewiring  of  the  aircraft.  The  primary  requirement  of  the 
signal  sources  and  displays  Is  that  they  are  compatible  to  the  characteristics  to  be  defined  for  both 
the  video  bus  and  data  bus. 

Each  display  unit  contains  a  Digitally  Tuned  Receiver  (DTR)  that  Is  connected  to  a  data  bus. 
Commands  can  be  sent  through  the  DTR  over  the  date  bus  to  tune  a  display  to  receive  video  from  any  of 
the  external  sources,  generally  sensors,  TV  missiles,  or  the  Raster  Symbol  Generator  (RSG)  located  In 
the  avionics  bay  of  the  aircraft.  The  RSG,  through  a  DTR,  can  be  commanded  to  receive  the  sensor 
data  and  combine  It  with  symbology  and  retransmit  the  combined  video  signal  to  a  crew  station  display 
unit. 


Iji  " 
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To  ensure  fall-safe  conditions,  two  video  buses  and  two  data  buses  would  be  Installed  with  the  bus 
controller  monitoring  bus  operation.  Should  the  controller  detect  failure  of  one  bus,  the  second  bus 
would  be  reconfigured  to  operate  In  a  degraded  mode  to  permit  transmission  of  required  signals.  A 
priority  system  would  have  to  be  developed  as  a  function  of  critical  parameters  to  be  defined  to  enable 
succeasful  completion  of  the  aircraft  mission. 

5.  Operator/Machine  Interface 

The  operator/machine  Interface  Is  receiving  more  and  more  attention.  The  use  of  multifunction 
displays  and  controls  hopefully  will  preclude  the  following  results  of  a  study  of  five  years  of  Naval 
aircraft  accidents: 

•  Incorrect  use  of  emergency  procedures:  33  aircraft  destroyed,  13  aircraft  damaged,  19  fatal¬ 
ities. 

•  Incorrect  use  of  checklist:  5  aircraft  destroyed,  18  aircraft  damaged. 

•  Lack  of  stabllator  position  Indicator  (peculiar  to  F— 4) :  8  aircraft  destroyed,  6  fatalities. 

•  Lack  of  subsystem  malfunction  advisory  information:  42  aircraft  destroyed,  65  aircraft  damaged, 
75  fatalities. 

•  Lack  of  midair  warning  system:  8  aircraft  destroyed,  7  aircraft  damaged,  10  fatalities. 

•  Lack  of  VN  envelope  information  to  pilot:  42  aircraft  destroyed,  8  aircraft  damaged,  27 

fatalities. 

•  Lack  of  VQ  envelope  information  to  pilot:  18  aircraft  destroyed,  5  aircraft  damaged,  20 

fatalities. 

•  Lack  of  altitude  warning  system:  34  aircraft  destroyed,  6  aircraft  damaged,  59  fatalities. 

•  Inadequate  precision  approach  Information:  15  aircraft  destroyed,  46  aircraft  damaged,  4 

fatalities. 

•  Inadequate  CVA  precision  departure  Information  (reverse  ACLS):  16  aircraft  destroyed,  21 

fatalities. 

•  Lack  of  accurate  rate-of-sink  Indications:  6  aircraft  destroyed,  2  aircraft  damaged,  7 
fatalities. 

What  Is  required  Is  the  capability  to  demonstrate  a  coherent  solution  to  the  problem  of  prolifer¬ 
ation  and  nonstandardization  of  aircraft  displays  and  controls.  To  achieve  this  purpose,  efforts  are 
being  directed  toward  development  of  crew  stations  based  upon  digital  computers,  utilizing  s  high-order 
programming  language.  The  flexibility  of  such  digital  computers  and  their  accompanying  digitally 
driven  displays  has  created  radically  new  capabilities  to  be  utilized  in  the  design  of  crew  stations. 
The  total  dependence  on  the  use  of  dedicated,  round-dial  and  taped  Instrument,  Is  at  an  end.  The 
digital  computer  allows  the  implementation  of  multlprogrammable  electro-optica  displays,  such  as 
those  used  In  the  F-18;  It  also  allows  for  the  use  of  programmable  controls  such  as  those  used  in  the 
F-16  stores  management  panel.  The  electro-optical,  multifunction  displays  and  controls  offer  signi¬ 
ficant  advantages  over  their  dedicated  counterparts  in  that  one  electro-optical  display,  through  the 
use  of  various  display  format  changes,  can  encompass  the  information  presented  on  many  dedicated 
displays.  Early  emphasis  In  both  Air  Force  and  the  Navy  has  been  on  transferring  formats  from  electro¬ 
mechanical  Instruments  to  cathode  ray  tubes  (CRT's).  The  product  of  these  early  efforts  has  come  to 
fruition  and  Is  extensively  employed  In  the  F-18  aircraft  snd,  to  a  more  limited  extent,  In  the  F-16 
aircraft.  There  Is  reasonable  concern  that  the  pilot  may  have  trouble  in  fully  utilizing  the  tremendous 
amount  of  alphanumeric  Information  currently  being  presented  to  him  on  the  execCr— optical  devices. 
We  may  have  reached  a  state  where  the  Information  processing  of  the  human  Is  a  limiting  factor  in  the 
use  of  more  alphanumeric  Information.  The  answer  to  this  concern  and  the  objective  of  this  effort  Is 
the  simulation  and  evaluation  of  new  formats  that  are  based  upon  vectorgraphlc  or  pictorial  Information 
as  opposed  to  the  alphanumeric  Information  that  has  been  used  In  the  past. 

6.  Software  Interface 

The  software  Interface,  If  standardized,  will  provide  a  graphics  programming  system  that  offers 
the  advantages  of  high-level  support  and  facilities  to  meet  the  unique  technical  requirements  for 
multifunction  displays  and  controls.  In  addition,  ether  advantages  are: 

•  Reduced  cost  of  programming, 

•  Increased  assurance  of  software  reliability. 

•  Reduced  cost  through  ease  of  modification, 

•  Portability  and  reusability  through  processor  and  display  device  Independence. 

•  Improved  software  through  utilization  of  state-of-the-art,  real-time  graphics  techniques. 
The  software  functional  requirements  have  been  divided  into  the  following  three  groups; 


•  Hardware  evaluation 


f 


9-7 


x 


•  Operational  requirements 
e  Support  requiraaents 
Operational  Software 

The  AIDS  operational  software  provides  the  envlroonent  In  which  the  application  aoftware  are  run. 
This  environment  may  be  considered  a  virtual  machine  with  a  well-defined  software  interface,  applicable  to 
a  wide  variety  of  processor  and  system  architectures.  Even  when  the  underlying  physical  machine  changes, 
the  software  interface  to  the  virtual  machine  will  still  remain  the  same. 

The  services  provided  may  be  divided  Into  four  general  categories:  executive  functions;  input/output 
functions;  file  system  functions;  and  reconfiguration  control.  Executive  functions  include  processor 
and  primary  memory  allocation  and  Intertask  communication  and  coordination.  The  input/output  functions 
govern  all  transactlona  between  the  AIDS  data  processor  and  any  external  device.  File  system  functions 
provide  access  to  data  organized  aa  unit a  of  related  information.  The  reconfiguration  control  functions 
maintain  alternative  sources  for  critical  data  and  help  the  applications  functions  to  determine  which 
peripherals  are  usable. 


Support  Software 

This  software  is  composed  of  various  tools  associated  with  the  Naval  Air  Development  Center's  Central 
Computer  Complex  and  Includes  items  needed  to  develop  the  operational  software.  The  two  most  important 
tools  are  the  AIDS  Display  Formatter  (ADF)  and  the  AIDS  Command  Formatter  (ACF). 

The  ADF  la  a  system  for  preparing  the  AIDS  display-driving  software.  The  actual  mechanics  of  trans¬ 
lating  display  formats  into  display  programs  are  handled  by  a  graphica,  real-time  display  language.  In 
order  that  these  display  programs  can  communicate  with  the  display  update  programs  that  are  part  of  the 
Operational  Display  Software  (ODS),  some  conventions  on  naming  of  the  rapid  changes  will  be  promulgated. 
The  display  update  programs  will  pass  the  appropriate  name  to  the  graphics,  real-time  diaplay  language 
run-time  routines  that  will  search  for  the  name  in  the  record  of  image  structure  in  order  to  locate  the 
appropriate  modlf lcatlon  code  to  be  passed  to  the  Symbol  Generator(s) .  A  pictorial  representation  of  the 
ADF  is  shown  in  Figure  2. 

The  ACF  is  a  translator  that  accepts  statements  in  the  AIDS  Command  Language  (ACOL)  and  produces  data 
declaratlona  in  CMS-2  for  inclusion  in  the  data  processor  source  modules  as  well  aa  data  declarations  in 
the  microprocessor  assembly  language  for  inclusion  in  the  source  modules  located  in  the  Integrated  Control 
Set  (ICS)  Itself.  The  ACOL  statements  completely  define  the  facilities  provided  to  the  pilot  on  the 
ICS. 


The  microprocessor  assembly  language  data  definitions  specify  a  hierarchical  structure  of  ICS  states, 
along  with  button  labels  and  button  depression  responses  appropriate  to  those  states.  The  responses  may 
be  Internal  to  ICS  (for  example,  changing  an  ICS  atate  in  response  to  a  button  depression)  or  may  Involve 
ICS  sending  a  command  to  the  data  processor.  The  CMS-2  data  definitions  describe  these  commands;  the 
definitions  cover  command  code,  data  sources  and  command  destination.  A  pictorial  representation  of  the 
ACF  is  shown  in  Figure  3. 


nCTURE 

GENERATION 

PROGRAM 


Figure  2.  AIDS  Display  Formatter  (ADF) 
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Figure  3.  AIDS  Commend  Formatter  (ACF) 


CONCLUSIONS 


Military  airborne  platforms  of  the  1990' s  will  require  an  expanded  and  reliable  human-machine  Interface 
with  crew  station  Instrumentation  In  order  to  optimize  the  tactical  position  of  the  pilot.  State-of-the- 
art  advancements  In  display  hardware  and  In  software  and  Interface  designs  are  critically  needed  to  achieve 
weapon  system  crew  station  Instrumentation  that  Is  adaptable  to  many  platforms.  The  display  and  control 
Interfaces,  as  shown  In  Figure  1,  portray  the  four  crew  station  hardware  Interfaces,  the  human-machine 
Interface,  and  the  software  Interface  that  would  meet  these  needs. 

However,  as  new  and  Improved  hardware  and  software  become  available,  the  life-cycle  costs  oust  be 
reduced  In  order  to  achieve  the  necessary  operational  effectiveness  of  the  future  weapon  systems.  Rigid 
controls  In  the  design  and  Integration  of  the  six  Interfaces  la  crucial  to  the  reduction  of  life-cycle  costs 
previously  described.  Reduction  of  these  costs  will  be  the  only  way  that  these  systems  will  be  Introduced. 
An  Improvement  In  the  effectiveness,  adaptability,  and  supportablllty  of  crew  station  Instrumentation, 
described  In  the  Background  will,  of  course,  be  possible  only  If  these  Innovative  concepts  are  Indeed 
Introduced  Into  the  fleet.  To  attain  the  desired  mission  requirements,  the  specification,  production  and 
control  of  these  six  Interfaces  must  be  established  to  achieve  crew  station  compatibility  for  mulclplatform 
applications. 
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DISCUSSION 


W.R  Johnson,  US 

It  has  been  my  experience  that  it  is  extremely  difficult  to  sell  Life  Cycle  Cost  Savings  if  it  results  in  significant 
increase  in  initial  procurement  cost.  Do  you  have  an  idea  as  to  how  to  handle  this  problem? 

Author’s  Reply 

I  have  had  the  same  experience.  It  is  forums  like  this  that  should  be  utilized  to  convince  high  level  decision  makers 
that  life  cycle  cost  consideration  is  the  only  long  term  solution.  Short  cuts  today  and  bandaids  later  to  fix  the 
mistakes  are  self-defeating. 


A.O.Ward,  UK 

ia  tfifc  diapiay  au  11  w  a  i  t  piudaeed  by  yuor  u  ft lilt-  System  tuily  interactive  ut  rt  it  juSl  animated  te  show  tlaeX 
movement  of  symbology? 

Author’s  Reply 

Both  the  display  and  the  multifunction  control  software  are  completely  interactive. 
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LE  COMBINE  DE  VISUALISATION 

PAR 

Madame  SIMON 

AVIONS  MARCEL  DASSAULT  -  BREGUET  AVIATION 
78,  Quai  Carnot 
92214  SAINT-CLOUD 

RESUME 

L'appellation  "combine  de  visualisation"  correspond  &  un  ensemble  mfecanique  unique  regroupant  un 
viseur  tfete  hauta  et  un  fecran  tfete  basse.  Las  imageries  tfete  haute  sont  prfesentfeas  colllimatfees,  les  imageries  t6te 
basse  peuvent  3tre  collimatfeas  ou  focalisfees  dans  un  plan  fixe. 

Un  tel  systfema  permat  d'envisager  la  possibility  de  divers  types  d'utilisation  : 

-  extension  du  champ  viseur  vars  le  bas,  lorsque  la  visualisation  tete  basse  est  collimatfee. 

-  un  allfegement  de  la  symbologie  tete  haute  par  une  meilleu’e  repartition  sur  tout  le  combine,  lorsque  la 
visualisation  tfeta  baase  est  collimatfee. 

-  lorsque  la  visualisation  tete  basse  est  focalisfee  &  una  distance  fixe,  elle  peut  fetre  aasocifee  fe  un  autre  fecran  tete 
basse  en  planche  tie  bord. 

INTRODUCTION 

Les  probifemes  de  transition  au  passage  visualisation  tfete  haute  -  visualisation  tete  basse  (accomodation 
de  l'oeil,  discontinuity  de  l'informetion),  nous  ont  amend  fe  proposer  un  concept  de  combine  de  visualisation  ;  il 
s'agit  d'un  ensemble  mycanique  unique  regroupant  un  viseur  tfete  haute  et  un  fecran  tfete  basse,  utilisant  de  nouvelles 
technologies  :  optiques  fe  diffraction,  coltimation  des  imageries  tfete  basse. 

Ce  concept  doit  permattra  d'amfeliorer  l'efficecity  des  fechanges  pilote  -  systfeme  d'armes,  en  utilisant  la 
partie  tfete  basse  soit  collimatfee,  soit  focelisfee  fe  une  distance  fixe.  Diffferents  types  d'utilisation  seront  envisages 
dans  ce  papier,  cet  propositions  rastsnt  dfependentes  de  le  faisabilitfe  technique. 


1 -ORGANISATIONS  DES  PLANCHES  DE  BORD  ACTUELLES 


1.1  -  Repartition  das  systfemes  de  visualisation 


11  existe  actueilement  deux  categories  de  systfemes  de  visualisation  : 


des  systfemes  dlts  "tfete  haute"  :  I'lmagerle  est  alors  visualises  collimatfee,  fe  travers  un  viseur,  situfe  au-dessus  de 
la  planche  de  bord,  et  permettant  le  pilotage  de  l'avion,  (pilotage  de  base  et  action  k  court  terme  en  fonction  de 
la  phase  de  la  mission  en  cours)  par  l'obervation  simultanfee  du  paysage  extferieur  et  des  informations  vues  en 
superposition. 

des  systfemes  dits  "tfete  basse"  :  I’lmagerle  est  alors  visualisfee  non  collimatfee  sur  un  ou  plusieurs  fecran*,  situfes 
sur  la  planche  de  bord,  permettant  la  presentation  des  Images  dfellvrfees  par  les  diffferents  capteurs  embargoes  ou 
autres  dlspositlfs  dfellvrant  une  vidfeo  et  servant  dlnterfacs  SNA  par  I'lntermfedialre  de  commandes  pdrtphferlques. 
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1.2  -  Etudes  des  diffjrgnts  problfemes 

,1.2.1  -  Transition  optique  tflte  haute  -tflte  basse 

Le  passage  des  visualisations  presentees  focalisees  &  l'infini  en  tSte  haute,  aux  visualisations  non 
collimatfles  en  tflte  basse,  presentees  dans  le  plan  dt  la  planche  de  bord,  pose  un  problflme  d'accomodation  de  I'oeil, 
de  mflme  que  la  difference  de  lumirtosite  moyenne. 

De  plus  un  £cran  t§te  basse  ne  se  trouve  jamais  directement  sous  le  collimateur  tSte  haute.  L'oeil  a 
done  un  certain  circuit  &  parcourir,  circuit  qui  peut  fltre  encore  plus  grand  s'il  doit  aller  "chercher"  des  ecrans  tflte 
basse  latflraux. 

1.2.2  -  Transition  du  type  d'imaqene  tflte  haute  -  tflte  basse 

Chacun  des  deux  systflmos  de  visualisation  presente  des  imageries  souvent  specifiques  sans  continuite 
dans  ('information  presentee  ceci  bien  evidemment  en  partant  du  principe  que  des  images  collimatees  en  tflte  haute 
et  toujours  non  collimatees  en  tflte  basse  ne  peuvent  avoir  que  des  utilisations  bien  differentes. 

En  effet  suivant  les  phases  du  vol,  le  pilote  souhaile  travailier  en  gardant  la  vue  sur  l'exterieur  (e'est  le 
cas  chaqut)  fois  que  ses  centres  d'interets  peuvent  fltre  observes  au  dehors)  ;  il  utilise  alors  le  viseur.  Par  contre 
lorsque  ses  centres  d'interet  sont  hors  de  vue,  il  r.e  peut  que  se  reporter  en  tflte  basse  pour  y  chercher  une 
information  deiivree  par  1‘intermediaire  de  capteurs. 

1.2.3  -  Charge  d'informations  presentees  sur  le  viseur 

Les  imageries  tSte  haute  sont  souvent  chargees  d'informations  statiques  non  superposables  au  paysage 
et  qui  gflnent  la  vision  du  monde  exterieur. 

2  -  DEFINITION  DU  COMBINE  DE  VISUALISATION 

Pour  tenter  d'apporter  des  solutions  aux  problflmes  evoques  au  chapitre  precedent,  il  faut  un  systfeme  de 
visualisation  plus  homogene  physiquement  et  optiquement,  meins  dissociable  e'est-fl-dire  s'adaptant  indifferemment 
e  plusieurs  types  d'imageries. 

Ce  systeme  sera  presente  sous  le  nom  de  :  combine  de  visualisation. 

Les  differents  types  d'utilisation  du  combine  ie  visualisation,  qui  serent  evoques  dans  ce  papier,  doivent 
fttre  considerds  comme  des  objectifs  repondant  aux  probiemes  poses,  mais  restant  dependant  de  la  faisabilite 
technique. 

2.1  -  Le  combine  de  visualisation 

Le  combine  de  visualisation  est  un  ensemble  mecanique  unique  regroupant  un  viseur  tflte  haute  et  un 
ecran  tflte  basse.  Ce  concept  de  combine  permet  de  minimiser  I'epaisseur  du  ilnteau  horizontal  separant  le 
collimateur  tflte  haute  (CTH)  et  la  visualisation  tflte  basse  (VTB). 

Le  collimateur  tflte  haute  peut  fltre  solt  un  viseur  8  optique  classique,  soit  un  viseur  utilisant  les 
rtouvelles  technologies  d'optique  6  diffraction  (glace  holographique)*.  La  visualisation  tflte  basse  presente  des 
imageries  qui  peuvent  fltre  soit  colllmetees,  soit  focalisees  dans  un  plan  partlculier. 

2.2  -  Types  d'utilisation 

Le  combine  de  visualisation  pourra  fltre  utilise  de  deux  fagons  : 

-  VTB  collimatee  :  les  imageries  tflte  basse  etant  focalisees  fl  l'infini,  on  annule  einsi  les  probiemes  c,  adaptation 
visuelle  au  passage  ttte  haute  •  tftte  basse.  Cet  ensemble  est  alors  utilise  pour  presenter  : 

.  une  imagerie  unique  partant  du  champ  viseur  et  s'etendant  vers  le  bas  au  champ  t§te  basse,  superposable  au 
peysage  exterieur  (paysage  effectivement  pergu  8  travers  le  viseur  pour  une  pertle  et  qui  serait  vu  8  travers  la 
planche  de  bord  et  le  nez  de  I'avion  s'ils  etalent  transparents  pour  l'autre  partie) 

•  Nous  n'envisageons  par  la  suite  que  cette  2 feme  solution. 
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.  una  imageria  diffdrente  en  t«te  basse  de  calle  du  viseur  qui  permettra  par  exemple  lorsque  le  chamr  viseur  est 
suffisant,  une  meilleure  repartition  des  informations  tout  en  permettant  une  transition  ais6e  tete  naute  -tete 
basse. 

-  VTB  focalisee  b  una  distance  fixa  :  les  imageries  tete  basse  ne  sont  plus  collimatees.  Cette  configuration  est  plus 
adaptde  b  l'association  "visuelle"  avec  le  ou  les  autres  Scrans  tftte  basse  et  correspond  plus  b  l'utilisation 
actuella. 

2.3  -  Solutions  apportSes 

Le  combine  ainsi  realise  permet  : 

-  une  amelioration  de  la  transition  tete  haute  -  t@ta  basse  et  possibilite  d'extension  du  champ  viseur  en  utilisant  la 
tete  basse  collimatee 

-  une  utilisation  de  la  teta  basse  plus  adaptee  b  cheque  phase  de  mission,  c'est-b-dire  non  specifique  d'un  type  de 
visualisation 

-  une  plus  granda  homogeneTte  des  informations  presentees  qui  ne  sont  plus  specifiques  de  l'ecran  tete  basse  sur 
lequel  alles  apparaissent,  mais  de  l'utilisation  choisia  du  combine. 


3  -  AMENAGEMENT  EN  CAB1NE 

Nous  considfererons  l'3menagement  du  combine  de  visualisation  dans  l'avion,  en  se  basant  sur  l'orga- 
nisation  futur  du  poste  d*gquipage  telle  que  nous  l'envlsageons. 

3.1  -  Description  de  l'anvironnement  cabine 

L'amenagement  de  la  cabine  repose  sur  la  conception  du  sibge  pilote  qui  permet  une  meilleure  tolerance 
aux  facteurs  de  charge  eieves.  Pour  ce  faire,  le  dossier  du  siege  est  incline  d'un  angle  de  50°  avec  l'axe  z. 


La  premiere  consequence  importante  est  que  le  manche  et  la  manette  des  gaz  ne  peuvent  fttre  que 


lateraux. 


La  seconde  est  que  la  planche  de  bord  se  trouve  alors  rdduite  b  une  bande  verticale  (comme  le  montre  la 
planche  1)  at  b  deux  petits  panneaux  implantes  au-dassus  des  pieds. 

Cet  amenagement  permet  l'installation  des  equipements  de  visualisation  sur  la  bande  verticale, 
d'instrumants  de  secours  sur  les  planchettas  da  bouts  de  pieds,  de  claviers  sur  1'avant  des  banquettes 


Planche  n"  1 
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3.2  -  Integration  du  combing  de  visualisation 


Dans  un  tel  contexte,  le  combine  de  visualisation  s'intfegre  facilement,  comme  indique  sur  le  dessin  ci- 


dessous  : 


Combine  de  visualisation 


Ecran  tfite  basse 


CTH  :  collimateur  tete  haute 


VTB  1 :  visualisation  tete  basse  1 


VTB2  :  visualisation  tete  basse  2 


La  VTB2  faija.it  suite  au  combine,  est  un  ecran  tete  basse,  presentant  des  imageries  dans  le  plan  de  la 
planche  de  bord,  tel  qu'il  est  actuellement  utilise. 

Cette  installation  perrnet  une  visualisation  dans  un  seul  axe  (haut-bas  ou  bas-haut)  dont  la  transition 
sntre  cheque  terminal  est  fonction  du  type  d'utilisation  du  combine. 


4  -  PERFORMANCES  ET  UTILISATION 


4.1  -  Performances 

Le  collimateur  t6te  haute  dit  "holograph ique"  est  caracterise  par  : 

-  la  presentation  d'un  champ  de  30°  en  lateral  sur  20°  en  vertical 

-  la  visualisation  d'imageries  trichrome. 

La  t6te  basse  VTB1  est  caracterisee  par  ; 

-  deux  plans  de  localisation,  soit  l'infinl,  soit  le  mSme  plan  que  VTB2,  c'est-4-dire  le  plan  de  la  planche  de  bord.  Le 
passage  d'un  plan  4  l'autre  pourra  6tre  soit  automatique  (automatisme  declenche  par  la  phase  de  la  mission  en 
cours)  soit  manuel 

-  la  visualisation  d'imageries  polychromes 

-  la  face  avant  est  un  rectangle  de  grand  cflte  horizontal,  de  dimensions  angulaires  (ramendes  4  la  distance  de  la 
VTB2),  dquivalentes  4  7"  x  5"  . 

Nota  :  La  face  avant  de  VTB2  est  un  carrS  de  7"  de  cflt4. 

Les  Imageries  pr4sent<es  sont  polychromes. 

4,2  -  Utilisations 

4.2.1  -  Utilisation  VTB1  colllmat6e 
4,2.1. 1-  En  extension  du  champ  viseur 

Le  princIpe  d'utilisation  est  alors  la  visualisation  au  centre  du  CTH  et  dsns  le  prolongement  sur  la  VTB1, 
d'une  imagerie  superposable  au  paysage  extdrieur,  pouvant  provenir  d'un  gdndrateur  de  terrain  et/ou  d'un  boftier 
g<n<rateur  de  symboles. 

Sur  cette  Imagerie  viennent  s'ajouter  les  reticules  de  pilotage  et  les  rdticules  spe.'ifiques  de  la  phase  de 
la  mission  en  cours,  qul  constituent  une  liste  unique  pour  le  combing,  et  peuvent,  done,  dans  la  limite  de  leur 
domaine  opdrationnel,  passes?  indiffiremment  du  CTH  4  la  VTB1  et  rdciproquement. 

I 


Ce  "fond  vid<o"  et  reticules  assocKs  constituent  alors  le  centre  d*int6r4t  du  pilote. 


10-5 


Les  fonctions  commandas  et  consultation  aont  visuallsdas  dans  l'espace  restant  c'ast-d-dire  sur  las 
bandeaux  latdraux. 

Sur  le  CTH,  on  presente  en  bandeau  tous  las  reticules  fixes,  c'ast-4-dire  las  compteurs,  dchelles, 
signalisations  de  mode  de  fontionnement. 

Sur  la  VT8  1,  on  prdsanta  en  bandaau  les  labels  correspondents  &  des  selections  de  mode  de 
fonctionnemant,  de  typa  da  visualisation,  compatibles  avec  la  phase  de  la  mission  en  cours. 

Un  rdticula  de  designation  peut  etre  deplace  indifferemment  de  la  tete  haute  &  la  teta  basse,  &  I'aide 
d'une  commande  &  accbs  rapida,  sarvant  aussi  bian  b  designer  un  labal  sur  la  VTB  1  ou  un  point  de  visde  sur  le  CTH. 

4.2.1.2-  En  aide  &  transition  tete  haute  -  tete  basse 

Dans  ce  moda  (^utilisation,  on  presente  sur  tout  le  champ  tete  haute  les  imageries  superposables  au 
paysage  at  en  tete  basse  las  informations  necessaires  d  la  phase  du  vol  en  cours  mais  non  directement  lides  au 
monda  axtdrieur,  par  example  les  compteurs,  las  dchelles. 

4.2.2  -  Utilisation  VTB  1  focalisde  &  una  distance  fixe 

(.'utilisation  tete  basse  correspond  plus  aux  habitudes  actuelles. 

La  VTB1  est  alors  "ddsolidarisee"  optiquement  du  CTH  pour  s'associer  4  la  VTB2.  Cette  utilisation 
correspond  plus  aux  phases  de  la  mission,  assistdes  d'imageries  non  projetables  en  tete  haute  ou  aux  phases  de 
preparation  du  syst&me  da  navigation  et  d'armemant  (SNA). 

L'association  des  imageries  VTB1  -  VTB2  peut  etre  de  plusieurs  types  : 

-  des  imageries  capteurs  sont  prdsentdes  sur  les  deux  dcrans  ;  elles  sont  operationnellement  complement ai res 

-  une  imagerie  capteur  ast  prdsentee  sur  I'un,  una  image  cartographique  sur  I'autre. 

•  une  imagerie  capteur  est  presentee  sur  I'un  et  la  "page"  de  commandes  ou  de  gastion  correspondents  sur 
1'autra. 

Dans  cartains  cas  de  consultation  du  systfeme  avion,  las  imageries  VTB1  sont  dissocides  de  celle  de 
VTB2,  pour  prdsanter  au  pilote,  un  tableau  das  pannes,  cfdtats  motaurs,  cfdtats  du  systdmes  radiocommunication. 

Dans  tous  les  cas  les  reticules  associds  sont  spdcifiques  de  I'dcran  sur  lequel  ils  sont  visualises,  des 
bandaaux  latdraux  sont  rdsarvds  pour  des  labals  permettant  I'acc&s  aux  commandes,  par  designation. 

5  -EXEMPLES  D'UTILISATION 


5.1  -  Utilisation  VTB  1  collimatde  : 


-  Presentation  du  relief  synthdtique 

Le  relief  synthdtique  est  une  representation  du  terrain  3urvold,  dlaborde  &  partir  d'una  mdmoire  da 
masse  contanant  las  donndes  numeriques  ndcassaires.  Ce  tarrain  se  superpose  en  t#te  hauta  au  terrain  rdel  survold 
et  se  suparposerait  en  tete  bassa  au  terrain  rdel  s'il  dtait  vu  (d'ou  le  concept  de  planche  de  bord  transparente). 

Cette  representation  permet  done  d'effectuer  das  vols  d  trbs  basse  altitude  qualles  ques  soient  les 
conditions  metdorologlques,  de  jour  ou  de  nult.  (voir  planche  2). 

La  projection  de  cette  imagerie  sur  le  combine  permet  par  rapport  aux  solutions  actuelles,  la 
representation  du  terrain  selon  un  champ  plus  etendu  en  longitudinal  et  en  lateral  ;  ce  proeddd,  dans  des  conditions 
de  mauvalse  vlslbilltd  donne  au  pilote  une  mellleure  perception  tant  au  niveau  perspective  que  richesse 
d'lnformations  du  relief  dans  lequel  il  dvolue. 

Dans  certains  cas  d'approches  particulidres  (relief,  endommagements...),  ce  type  de  representation  (voir 
planche  3),  sur  laquelle  peut  se  superposer  une  piste  synthetique,  dolt  apporter  une  meilleure  appreciation  des 
conditions  de  vol. 

a  L'exactitude  de  la  superposition  sera  dvidemment  IMe  b  la  precision  de  la  navigation. 
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La  VTB1  presente  1'image  d'un  capteur  optronique,  comportant  un  marqueur  de  designation  dans  sa 

video. 

La  VTB2  presente  1'imagerie  radar  en  fonctionnement  cartographique  (visualisation  du  sol). 

L'imagerie  eiaboree  par  le  radar,  utilise  alors  en  detection  de  cible  terrestre,  permet  £  l'aioc  d'une 
alidade  incrustee  dans  la  video,  de  designer  l'objectif  et  de  fournir  e  1'equipement  optronique  la  direction  de 
pointage  ;  cette  direct.on  est  materialisee  par  la  position  du  marqueur  de  designation  sur  la  VTB1,  marqueur  qui 
aidera  ensuite  &  la  poursuite  de  l'objectif. 
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Utilisation  en  poste  de  commande 


Dans  certaines  phases  de  navigation  oCj  le  piiote  a  le  temps  de  consulter  et  eventuellement  de  modifier 
le  plan  de  vol,  la  VTB1  peut-Stre  utilisde  en  poste  de  commande  de  navigation  tandis  que  la  VTB2  presente  la 
visualisation  du  plan  de  vol. 


Le  viseur  presente  alors  une  image  de  type  navigation,  telle  que  decrite  au  §  5.1.1. 


En  VTB1  ne  sont  alors  visualises  que  des  labels  ou  des  compteurs  servant  d'interface  nvtc  le  SNA,  les 
labels  permettant  des  selections  de  mode  de  fonctionnement  visualises  en  VTB2,  les  compteurs  presentant  des 
comptes-rendus  d'actions  effectuees  sur  VTB2. 
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6  -  CONCLUSION 


Dans  le  contexte  de  poste  d'dquipege  futur  meis  eussi  d'ores  et  ddjd,  1'installetion  d'un  combind  de 
visualisation  doit  permettre  une  meilleure  "rentebilitd  opdrationnelle"  des  dquipements  de  visualisation. 

Mais  il  est  certain  qua  son  efficecitd  sera  emdliorde  par  le  ddveloppement  de  concepts  nouveeux  tel  que 
le  gdndration  d'un  terrain  synthdtique  visuelisd  en  tSte  haute,  le  plenche  de  bord  trensperente,  de  technologies 
optiques  nouvelles  telles  que  les  optiques  5  dldments  holographiques. 


DISCUSSION 


P.Currier,  US 

Is  the  integrated  head  up/head  down  system  you  have  described  something  you  have  developed,  you  are  developing, 
or  you  would  like  to  see  developed? 

Reponse  d’Auteur 

Le  combing  de  visualisation  est  un  systeme  actuellement  en  developpement  chez  THCSF.  Cette  societe  nous  a  deja 
foumi  une  maquette  afin  d’effecteur  des  essais  d’integration.  Toutefois  cette  maquette  ne  correspond  pas  exacte- 
ment  au  systeme  prtsente  lors  de  la  conference,  notemment  quant  aux  performances,  (problemes  d’encombrement, 
de  volume). 


M.Burford,  UK 

While  the  proposed  IDS  solution  has  certain  ergonomic  advantages,  does  not  the  necessity  to  rake  the  pilot’s  seat 
backwards,  combined  with  what  appears  to  be  a  rather  large  inflexible  unit,  have  a  detrimental  effect  on  the  forward 
vision,  in  particular,  in  high  angle  attack  attitudes,  typical  of  the  landing  mode? 

Rlponse  d’Auteur 

Aux  grands  d’attaque  typiques  du  mode  atterissage,  la  compensation  de  la  perte  de  visibility  vers  l’avant  se  fait  en 
utilisant  la  partie  tete  haute  du  combine  collimatee,  ce  qui  permet  d’obtenir  une  extension  du  champ  viseur 
“artificielle”  vers  le  bas  et  la  presentation  d’une  piste  synthetique  (voir  planche  Approche)  restituant  ainsi  la  vision 
vers  l’avant  (concept  de  planche  de  bord  transparente). 


W.McKinlay,  UK 

Has  it  been  possible  to  measure  the  pilot’s  eye  activity  going  head  up  to  head  down  with  today’s  displays  so  as  to 
establish  the  difference  using  a  collimated  HDD?  Will  the  new  display  influence  the  amount  of  time  spent  heads 
out,  perhaps  by  being  more  compelling?  Will  it  have  any  unforeseen  effects  on  pilot/performance? 

Reponse  d’Auteur 

II  a  ete  dtabli  avec  des  pilotes,  par  dialogue  avec  eux,  un  besoin  de  visualisation  proche  du  HUD  et  rapidement 
exploitable:  une  proposition  de  collimation  du  HDD  nous  a  semble  etre  une  reponse  a  ce  probleme,  reponse 
concr6tisee  par  ce  concept  de  combind.  L’utilisation  d’un  tel  equipement  devrait  pouvoir  rtpondre  aux  problemes 
que  j’ai  souleves  lors  de  mon  expose  mais  il  est  certain  qu’il  offrirait  certainement  des  possibility  d’exploitations 
nouvelles  des  visualisations. 

II  est  probable  que  son  utilisation  changerait  la  perte  du  temps  pass6  actuellement  en  tete  haute  et  en  tete  basse. 
dans  le  sens  d’une  augmentation  du  temps  passy  en  tete  haute  (en  utilisant  le  HDD  collimate)  mais  ceci  ne  pourrai! 
etre  confirm^  que  par  des  essais  au  moins  en  simulateur  de  vol. 
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GUIDELINES  &  CRITERIA  for  the  FUNCTIONAL  INTEGRATION 
of  Avionic  Systems  with  Crew  Members  in  command 


by 

Friedrich  W.  Broecker 

Federal  Agency  for  Military  Technology  4  Procurement  (B  W  B),  Koblenz,  W. -Germany 


Summary 


Significant  technical  hardware  advances  have  been  made  during  the  past  few  years  in 
digital-micro-technology  that  have  caused  problems  of  how  to  handle  and  how  to  use  their 
great  potential  for  the  best  benefit  of  designing  a  distinctly  better  system  and  working 
environment  for  the  crew  member  in  order  to  make  him  a  real  functional  member  of  the 
system.  Such  a  good  approximation  to  a  real  Functional  Integration  of  technical  means 
and  human  beings  seems  to  be  the  only  promising  way  for  a  distinct  improvement  of  weapon 
system  effectiveness. 

Although  the  human  member  of  the  airborne  system  has  not  made  at  all  comparable  performance 
advances,  he  is  increasingly  used  in  a  Superman  role,  required  to  integrate  and  monitor 
most  of  the  subsystems,  and  thereby  to  compensate  for  the  shortcomings  and  discrepancies 
of  the  total  weapon  system.  Last  but  not  least  the  primary  job  is  to  perform  a  mission  in 
hostile  environment. 

These  problematic  facts  have,  in  the  main,  been  recognised,  but  from  quite  different 
aspects,  depending  upon  company  and  country,  and  upon  the  personal  background/history  of 
the  respective  manager.  Consequently,  the  results  of  the  respective  conceptual  and 
developmental  approaches  differ  considerably.  Another  aspect  which  confuses  the  situation 
is:  everyone  seems  to  be  right,  because,  he  is  in  a  position  to  substantiate  his  thesis 
by  figures  of  pilot's  workload,  system  effectiveness  and  so  on  -all  based  on  tests  and 
computations.  The  main  reason  for  the  contradiction  between  Cockpit  reality  and  the 
assessment  thereof  seems  to  be:  everyone  is  right  within  the  boundaries  of  his  approach 
and  in  accordance  with  the  Guidelines  4  Criteria  he.  has  used,  thus  ensuring  they  do  apply. 

The  continuous  discussions  about  the  contradictory  conclusions  drawn  out  of  operational 
experience  and  some  attempts  of  substantiation  by  strange  theoretical  arguments  reveal 
an  unsolved  problem  of  vital  magnitude.  This  problem  can  probably  only  be  solved,  if  It  is 
not  treated  any  more  like  an  one-dimens ional/two-dimensional  task:  Technical  means  plus 
human  physics.  Therefore, we  shall  try  to  leave  the  current  pattern  of  thinking  and  find 
out  of  what  nature  the  factors/ i nfl uences  of  the  problem  are.  There  will  be  certai nly  also 
factors  of  mental  or  philosophical  nature,  of  wrong  inference,  of  aspects  and  a  kind  of 
mixture  of  several  above  mentioned  infl  uences  .A  wide  field  is  left  for  the  exploration  of  the  multi¬ 
dimensional  functional  Interactions  of  all  these  Interdisciplinary  factors. 

The  intention  of  this  paper  is  to  provoke  new  aspects,  the  designer  might  need  to  look  at  the 
problem  of  proper  functional  integration  of  man  4  technical  means.  Therefore  it  sketches 
briefly  the  operational  and  working  environment  for  the  crew,  discusses  several  different 
system  approaches,  and  attempts  to  describe  some  of  the  main  aspects,  guidelines  and  cri¬ 
teria  obviously  used  therein.  Finally  a  draft  of  Guidelines  4  Criteria  is  proposed  for 
discussion  within  AGARD,  whereof  an  important  element  is  the  proof,  that  an  information 
or  a  control  is  absolutely  needed  for  flight  safety  or  survival. 
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1.  Introduction 

This  decade  is  witnessing  a  revolution  in  the  design  requirements  for  integrated  &  automated 
airborne  avionic  systems,  a  revolution  whose  high  ranking  goal  must  be, among  others,  to 
develop  a  man-machine  interface,  tailored  most  perfectly  to  the  needs  of  the  human  link  in 
the  different  loops.  The  latter  requirement  is  the  main  subject  of  this  paper  in  the 
functional  sense.  In  other  words,  this  does  not  mean  a  physical  tailoring  to  the  human  body 
and  his  biomechanics,  combined  with  a  perfect  interior  design.  This  physical  portion  of 
the  Functional  Integration  shall  not  be  neglected,  but  it  should  be  given  the  place  in  to¬ 
day's  complex  system  development,  that  it  only  can  claim:  A  supporting  function  at  the 
pilot's  side  of  the  instrument  panel.  Systems  ergonomics,  only  applied  at  the  pilot's  side 
of  the  instrument  panel,  is  history  for  a  few  decades! 

This  paper  is  therefore  mainly  concerned  with  what  is  behind  the  instrument  panel.lt  deals 
merely  with  the  search  for  a  most  human/intell igent  functional  matching  of  two  "dissimilar 
organism:",  human  brains  &  reactions  on  the  one  side,  and  technical  means  that  can  perform 
some  functions  like  sensing,  mechanical  actions  and  even  thinking  to  a  certain  degree,  on 
the  other  side.  The  aim  is  to  find  a  way  to  match  both  "partners"  in  such  a  way,  that  both, 
jointly  in  a  coordinated  and  complementary  operation,  perform  together  at  least  one  order 
of  magnitude  better  than  each  of  the  two  alone. 

This  paper  is  furthermore  an  attempt  to  underline  the  importance  of  the  first  few  phases 
in  the  progress  of  the  Systematic  Software  Engineering,  and  to  show  the  aspect-derived 
philosophy  used  in  order  to  identify  the  characteristics  and  nature  of  the  problems  to  be 
solved.  This  paper,  however,  does  not  devote  a  single  paragraph  to  computer  languages 
and/or  algorithmic  approaches.  This  will  not  mean  that  these  tool s/ veh icl es  are  not  impor¬ 
tant  for  the  development  of  a  complex  system  with  good  Functional  Integration.  For  this 
goal,  it  is  of  paramount  importance  to  do  the  first  few  phases  of  the  Systematic  Software 
Engineering  as  carefully  and  substantiated  as  possible,  up  to  the  phase  of  the  Functional 
Specifications.  They  must  be  oriented  towards  an  optimal  compromise  between  the  required 
systems  performance  and  the  technical  possibilities  on  the  one  hand,  and  the  constraints 
imposed  by  the  mental  and  physical  characteristics  of  the  human  link  on  the  other  hand. 

The  expression  which  best  describes  the  airborne  systems  Functional  Integration  is  "Man- 
Computer-Symbiosis",  named  by  J. Hopson,  W. Zachary  and  N.Lane  in  1981,(2),  because  both, 
the  crew  and  the  aircraft  have  literally  to  live  with  each  other. 

Isn't  all  that  already  incorporated  in  various  of  the  new  first  generation  aircraft  with 
micro-digital  avionics  with  the  MFC's  and  MFK's  ?  Don't  they  have  "SOME  KIND"  of  integra¬ 
tion  end  automation?  Aren't  they  all  praised  as  big  achievement,  called  "break  through's, 
watersheds,  quantum  jump's"  and  so  on  ? 

As  a  matter  of  fact,  they  all  are  the  result  of  different  attempts  to  make  optimum  use  of 
the  new  digital  technology.  And  they  all  have  remarkable  merits,  but  they  also  have  created 
some  new  problems,  more  or  less  compromising  or  even  reducing  totally  the  effect  of  the 
merits.  This  paper  is  therefore  also  trying  to  direct  the  attention  to  problems .which 
arise  due  to  inappropriate  software  engineering  of  vital  functional  integrations  .that  can 
materially  worsen  any  intended  improvement  of  the  system  effectiveness.  This  applies  to 
the  kind  of  Integration  as  weil  as  to  the  kind  of  automation.  This  “SOME  KIND"  is  the 
problem,  with  the  respective  priorities  among  the  functions  and  the  kind  of  functional 
interactions!  Just  modern  hardware  technology  alone  does  neither  make  automatically  a 
better  system,  nor  will  the  better  system  derive  from  endless  discussions  about  the 
computer  language  to  be  used.  It  must  be  said  once  more,  that  the  quality  of  a  complex 
system  is  mainly  determined  during  the  first  phases  of  the  Systematic  Software  Engineering 
up  to  the  Functional  Specification  ! 
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Enough  possibilities  are  left  during  the  following  phases  to  worsen  the  quality  of  the 
system.  But  those  possibilities  for  producing  shortcomings  and  performance  degradations 
are  not  of  a  vital  magnitude  anymore,  once  a  good  Functional  Specification  exists, 
although  the  possibilities  are  still  very  numerous  and  manifold! 


1.1  Non-Technical  Factors  and  the  Importance  of  their  Influence 


After  the  brief  mentioning  of  the  main  topics  of  this  paper,  and  the  attempt  to  explain 
their  nature  and  scope,  it  should  be  said, that  this  paper  will  also  try  to  stir  up  some 
new  aspects/ i nterrel at i onsh i ps ,  which  possibly  have  never  become  evident  before.  There  is 
even  a  high  degree  of  probability,  that  numerous  real  critical  problems/combinations  of  factors 
and  the  manifoldness  of  their  nature  have  not  yet  been  identified  at  all.  In  no  case,  is 
this  paper  intended  to  provide  "cookbook"  recipies  ! 

The  scope  of  vital  factors/ i nfl uences  is  multidimensional  and  therefore  of  a  highly  inter¬ 
disciplinary  nature.  The  complex  interrelationships  cannot  be  fully  understood  by  simple 
linear  thinking  (cause-effect),  a  method  we  usually  apply.  Probably  a  large  portion  of  the 
intricate  complex  interrelationship  is  already  identified,  but  scattered  in  small  pieces 
over  some  hundreds  of  different  human  brains,  without  any  interconnection  &  coordination, 
a  real  challenging  job  for  a  top  manager!  The  aim  of  any  manager's  work  in  the  area  of 
functional  integration  must  be  to  completely  inventory  all  respective  know-how,  in  order 
to  integrate  these  bits  &  pieces  into  a  homogeneous  entity  that  meets  the  specification. 

The  specialists  for  structures,  avionics,  propulsion,  aerodynamics,  aeromedicine  and  so  on 
have  each  their  own  aspects  and  priorities.  It  is  therefore  the  shaping  of  the  airborne 
system  and  the  degree  of  its  functional  integration  which  makes  evident  how  much  interdis¬ 
ciplinary  thinking  the  manager  is  able  to,  and  what  trade-offs  &  importance/weight  he  will 
allow  for  other  disciplines,  he  is  not  familiar  with.  Such  a  solo-management  depends  on  a 
series  of  individual  judgements,  and  the  quality  of  decisions  that  cannot  be  corrected.  In 
the  next  main  paragraph,  a  few  typical  examples  of  shaping  will  be  discussed. 

Since, in  future,  the  quality  of  crew  and  aircraft  become  increasingly  precious;  and  since 
their  number  decreases  accordingly,  we  shall  no  longer  be  able  to  afford  their  losses, 
because  we  need  them  and  their  aircraft  and  weapon  system  to  survive.  Not  even  in  peace¬ 
time  can  we  continue  the  risk  to  ignore  a  real  interdisciplinary  approach  in  an  optimal 
manner,  and  simply  accept  losses  as  being  inevitable.  Such  an  attitude  of  mind  is  fatalistic» 
and  of  vital  influence  upon  the  quality  of  the  total  system. 

This  must  be  emphazised,  because  in  reality  an  unacceptably  high  rate  of  total  losses,  man 
&  machines  occur  continuously  in  peacetime,  without  any  technical  mal function. A  leading 
NATO-officer  said,  that  there  is  extremely  strong  circumstantial  evidence  to  suggest,  that 
at  least  one  NATO  air  force  has  lost  several  pilots  and  new  aircraft  in  recent  years  because 
of  intolerable  increases  in  workload  at  critical  times  (Robinson,  B.L.  1981(1)).  In  some 
cases  even  highly  experienced  pilots  were  involved. 

This  refers  also  to  aircraft  with  micro-digital  avionics.  For  a  more  realistic  impression 
of  the  t  irguiirstfrfltti ,  utidtr  whiv.fi  tiit  -tntolvrAVe  Vhtraas*  iti  utAlwa  ttton,  you  v>A 

yourself  into  the  pilot's  position  in  the  cockpi  t, flying  100  ft.  high  in  bad  visibility, trying 
desperately  to  update  the  Nav/ Attack  system,  tomake  the  weapon  selections,  to  interprete  and  react 
to  threat  warning,  to  operate  coimruntcattoTi ,  to  locate  4  rttoijnite  targets  ana  to  stay  m  tuflratiuh 
all  at  the  same  time.  In  addition,  the  pilot  is  simultaneously  exposed  to  heat,  noise,  discomfort  in 
turbulence,  sweat,  excitement  and  the  grip  of  fear,  all  of  which  will  have  a  detrimental 
effect  on  the  mental  and  physical  fitness  of  the  man  in  the  cockpit. 
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Keeping  this  dramatic  situation  in  mind,  who  would  dare  to  go  on  with  the  current 
practice  to  blame  the  pilot  when  something  went  wrong  in  a  mission?  Because  it  is 
quite  easy  to  note  human  error/ fa i 1 ure ,  when  he  missed  one  control  action  out  of  some 
hundrfd  in  his  handbook/check  list,  or  mixed  up  the  sequence,  the  real  cause  will 
seldom  be  found.  The  following  Figures  show  symptoms  of  the  helplessness  in  the  field 
of  functional  integration  of  humans  and  technical  means  in  the  sense  of  symbiosis: 


F:g.1:  Number  of  Controls/Switches  per  crew  Fig.  2  :  Growth  of  Cockpit  Displays 

member  for  4  aircraft:  SPAD,  P-51,  (Source:  AGARDograph  255,  p  12-22) 

F— 111  and  F- 15. (Source:  AGARD  Confe¬ 
rence  Proceedings  No. 31 2,  Aug, 1981) 

The  facts  described  and  shown  above  present  a  phenomenon  which  is  not  brandnew.  But 
these  facts/factors/interrelation-ships,  and  the  interpretation  of  their  symptoms  will 
have  a  brandnew  qualitywhen  they  are  not  interpreted  any  more  as  mainly  be’ng  of  technolo¬ 
gical  nature,  or  simply  human  error. 

The  fatalistic  production  of  work  overload,  imposed  at  critical  times  upon  the  pilot,  should  mainly  be  blamed 
for  operational  incidents.  Is  it  really  enough  to  talk  about  the  “reduction"  of  workload  and 
to  do  only  some  partial  integration  in  limited  areas,  while  the  number  of  subsystems  and 
their  dedicated  indicators  &  controls  grows  faster  than  any  total  integration?  That’s  not 
really  a  working  concept,  as  the  above  described  operational  experience  shows. 

The  full  and  appropriate  use  of  today's  state-of-the-art  technology  is,  with  the  design 
methods  known  today,  mainly  limited  by  the  human  potential  of  comp-ehens i on  of  the  given 
information,  the  proper  decision  makings  the  human  fitness  potential  of  physical  A  reflex 
reaction  for  control  inputs.  Last  but  not  least, the  full  use  of  the  technological 

post  bilities  is  also  limited  by  the  “operator's"  actual  level  of  confi dence  in  his  ability 
to  perform  all  these  tasks.  We  cannot  change  the  man.  Proper  training  would  help,  but 
never  enable  him  to  cope  with  the  overload  of  the  high  volume  and  rate  of  information 
presented  to  make  the  necessary  high  quality  decision  in  a  matter  of  seconds. 

A  ngerous  and  obstinate  misinterpretation  seems  to  persist  in  most  corners  of  the 
military  avionic  world,  saying,  that  the  pilot/crew  should  be  kept  busy  to  an  unde¬ 
termined  degree  of  activity,  in  order  to  prevent  loss  of  competence/pro¬ 

ficiency  A  the  development  of  complacency  and/or  boredom.  It  might  be  possible  that  the 
source  is  the  paper  of  Curry  and  Wiener  (5),  published  in  1981.  It  must  be  stressed  here 
that  their  findings  apply  only  to  meciium/long-range  transport  flights  in  peacetime, 
as  is  typical  for  commercial  airliners,  for  example! 
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The  development  of  military  aircraft  systems,  however,  needs  a  different  systematic  and 
methodically  substantiated  way  .which  provides  an  optimum  of  potential  technical  means  to 
compensate  for  man's  inherent  disadvantages  in  today's  combat  environment.  This  means, 
we  have  to  endeavour  carefully  and  soundly  in  order  to  find  optimal  ways  for  the  most 
intelligent  use  of  available  technology,  we  are  capable  of. 

Bernhard  A.  Kulp  said  in  1982  (  6  )  "Perhaps  we'd  better  relieve  the  pilot  of  some  routi¬ 
ne  task  of  trajectory  and  attitude  control  (and  systems  monitoring)  so  he  can  turn  his 
attention  toward  targeting,  weapons  delivery  and  survival."  This  kind  of  thinking  is 
oriented  towardsa  rider  on  horseback.  Although  we  know  about  the  science  fiction 

character  of  such  an  ideal  symbiotic  interface  between  two  organisms,  the  orientation  sure 
is  right,  and  we  should  go  as  far  as  thinking  and  technology  possibly  allows.  This  sounds 
like  a  Guideline  which  might  turn  out  to  lead  to  a  concept,  whose  main  criterion  could 
become:  a  MINIMUM  of  "operator’s"  workload,  instead  of  only  REDUCTION! 

2.  Current  Approaches  &  Practice 


The  facts  described  above  have  been  widely  recognised,  and  many  different  attempts  have 
been  made  to  cope  with  the  complexity  of  the  task  by  using  different  approaches  of  inte¬ 
gration  and  automation,  based  on  different  philosophies.  The  results  of  those  different 
attempts  are  also  very  different,  as  pilots  know  by  own  experience  and  most  developers 
must  admit.  Each  of  these  approaches  and  philosophies  has  its  logic  in  itself  within 
the  boundaries  and  definitions  used  for  the  theoretical  or  methodological  bases,  as  far 
as  the  development  has  ever  been  t-ased  on  something  like  that. The  current, even  thelat'at 
attempts  .however,  have  one  thing  in  common :  they  all  fall  short  in  the  nor-\‘chriical  disciplines, 
some  more,  some  less.  The  thinking  and  working  boundaries  used  d-  rrmally  not  encompass 
all  the  main  factors  involved  in  the  intricate  complex  interrelet  t.nship.  The  main  defi¬ 
ciency  is  in  the  non-technical  area,  the  importance  that  one  will  allow/attribute  to  a 
function, and  wether  this  function  should  be  performed  at  all.  If  yes,  shall  it  be  performed 
exclusively  by  the  human  link,  or  by  technical  means,  ana  according  to  what  criteria  shall  such 
a  decision  be  made,  if  it  is'nt  predetermined  by  tradition  anyway.  Whatever  the  result 
of  these  considerations,  only  a  few  cases  have  become  known  where  old  traditional  pilot 
functions .associated  with  high  workload.have  been  taken  into  consideration  for  proper  auto¬ 
mation  ,  includinq  an  assessment  of  the  degree  and  type  thereof  (...  tailored  most  perfectly 
to  the  needs  of  the  human  link  in  the  different  loops!). 

The  normal  case  is  proliferation  of  functions  for  the  pilot,  additional  functions  in  order 
to  compensate  for  shortcomings  of  the  "technical  partner"  of  the  system,  caused  by  the  lack 
of  a  conceptual  methodology,  which  provides  also  for  the  inclusion  of  the  development  of 
“non-technical"  functions,  performed  by  technical  means.  A  comparison  of  the  different  de¬ 
grees  of  automation  for  mission  effectiveness  due  to  unloading  of  the  pilot  is  certainly  of 
high  interest. 

There  are  Top  Down  Approaches,  Bottom  Up  Approaches,  and  combinations  of  the  two  towards  auto¬ 
mation  and  integration,  based  on  different  philosophies.  Some  have  no  name  for  their  work, 
they  use  just  common  sense,  without  being  prisoner  of  a  theory  or  systematic  procedure. 

But  some  special  results  look  like  real  piecemeal  approaches,  addressing  only  -ingle 
subsystem  without  considering  the  overall  human  member  functions,  or  the  implicat  '  other 

automated  systems  interactions,  using  the  '"philosophy"  of  proliferation  of  comp  »■'  i,  all 
being  integrated  by  the  human  link.  Exactl.*  Superman'j job  description! 

The  distinct  decrease  of  displays  for  Future  Aircraft  in  Fig. 2  should  also  be  a  self-evident 
development  goal  for  the  number  of  dedicated  controls,  shown  in  Fig. 1.  Again,  this  requires  ori¬ 
entation  of  thinking  toward  the  horseback  rider.  A  horse  is  a  perfectly  integrated  and  automated  “CRAFT"  ! 
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The  science  fiction  vision  of  the  "man-horse-symbiosis"  is  certainly  not  properly  placed 
under  a  headline  of  “current  practice".  It  illustrates  the  distance,  however,  to  some  of 
the  current  approaches  sketched  briefly  hereafter.  Supposedly  the  following  Cockpit- 
caricatures  -referring  to  the  centra  1 / v i tal  part  of  a  manned  airborne  system-  are  mainly 
conceived  and  developed  for  the  same/very  similar  tactical  requirements.  Their  characte¬ 
ristics  .however,  are  sometimes  as  follows: 

1. The  interior  designer  type  believes  in  hardware  with  a  nice  front  in  the  cockpit.  The 
interface- function  between  man  and  machine  is  mainly  of  optical  and  haptic  nature.  Nice 
to  look  at,  legible  and  very  handy.  Besides  these  main  subjects, he  reluctantly  admits 
there  is  also  a  little  noise,  heat,  vibration  and  others,  all  of  minor  importance.  That's 
all  what  he  knows  about  ergonomics  and  their  considerable  impact  on  systems  effectiveness. 
Therefore,  he  looks  at  the  problems  as  the  most  practical  and  nicest  arrangement  of  the 
controls  and  indicat i ons/di spl ays  within  the  available  space  of  the  cockpit.  MFD's  and 
MFK's  are  welcome  because  they  look  modern  and  they  bring  about  a  relief  of  tne  “real 
estate"-problen  in  the  cockpit. 

The  i n ter i or  designer  does  not  ask,  whether  al  l  those  control - i nputs  and  indicated/dis¬ 
played  informations  are  necessary,  useful!  and  right,  or  how  much  workload  they  put  on  a 
man  in  a  critical  mission  p^ase,  while  he  is  also  very  busy,  incidentally,  to  fly  a 
mission. Complex  systems  interrelationship  and  the  appropriate  software  is  something 
mystical,  and  therefore  other  peoples  business.  To  him  the  interdisciplinary  range  is 
limited  to  the  cockpit  interior,  biomechanics  and  the  personal  comfort  of  the  crew. 

2.  The  electronics  freak-type  uses  the  most  modern  -even  immature-  electronics.  His  system 
is  the  maximum  of  any  possible  sophistication  among  all  others.  His  electronic  world 
looks  bright  and  clear,  when  he  can  present  his  creation  to  show  all  the  dazzle  of  his 
light  and  sound  spectacle.  He  will  produce  an  information  rate  and  volume  of  such 
magnitude  that  the  crew  members  become  unable  to  cope  with  it,  in  a  real  airborne  cockpit. 

He  is  proud  when  visitors  are  amazed  or  confused  -he  does  not  realize  the  difference- 
about  the  incredible  span  &  scope  of  electronic  possibilities  and  variations  thereof. 

He  plays  masterly  with  hundreds  of  buttons/keys  and  controls  and  seems  to  have  three/four 
hands,  because  he  can  simultaneously  point  to  lights,  indicators  or  other  events  which 
appear/happen  as  a  result  of  his  finger  activities,  according  to  his  explanations. 

In  case,  one  of  the  visitors  really  understood  what  happened,  and  comes  back  a  few  weeks 
later,  almost  everything  is  different,  and  the  explanation  will  start  all  over  again 
including  light  and  sound. 

One  day  the  development  must  be  frozen  and  the  users,  the  pilots,  shall  learn  several 
hundreds  of  pages  in  the  dash-one-handbook  plus  the  simulator  and  cockpit  training  hours, 
weeks  ,  month . . . . 

When  such  an  aircraft  crashes  one  day,  this  case  will  be  listed  under  attrition  rate; 
observation:  human  error/ fai 1 ure  ! 

3.  The  old  war-horse  type-cockpit  maker  does  not  give  very  much  thought  to  the  workload  pro¬ 
ducing  non-automated  functions.  For  him  simply  the  nature  of  workload  has  changed  from  the 
real  face  to  face  and  almost  physical  fighting  with  Spi tfi re ' s .Mustang ' s ,  Messerschmi tt ' s 
to  the  kind  of  mental  workload  associated  with  modern  technical  means.  This  type  of  gear 
requires  information  absorption,  interpretation,  decision  making  and  ac ti on/ react i on  , 
-without  seeing  the  adversary.  He  is  damned  right!  It  is  our  problem  to  cope  with  the 
fundamental  change  of  the  nature  of  workload.  The  attitude  of  the  war-horse  type  toward 
workload  is:  The  job  must  be  done,  and  can  be  done,  provided  proper  training  and  enough 
warriors  are  in  the  planning. 

He  admits  that  there  is  an  interaction  between  workload  and  systems  effectiveness.  In  case 
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the  workload  appears  too  big  to  him  for  a  single  man,  his  simple  conclusion  to  get  out 
of  this  situation  is  to  divide  the  workload  between  a  two-man  crew  or  more. 

While  thinking  everybody  is  doing  his  part,  without  a  too  heavy  burden  of  a  workload,  he 
could  not  be  more  wrong,  for,  in  reality,  this  has  nothing  to  do  with  job  sharing  as  it 
is  practiced  in  industry.  What  the  two  man  of  a  crew  really  must  do,  is  the  performance 
of  complementary  work  elements.  These  elements,  however,  do  not  give  the  prerequisite  of 
the  necessary  functional  integrity,  when  performed  individually. 

The  high  quality  decisions  necessary  within  a  severely  restricted  time  frame  are  only 
possible,  when  these  elements  are  done  simultaneously  and  every  one  knows  at  any  time 
what  the  other  does/intends  to  do. Such  on  interrelation  requires  a  mental  and  functional 
matching  of  two  (or  more)  "similar  organisms",  an  additional  person-to-person  interface! 
This  interface  brings  with  it  all  associated  problems,  so  as  to  obtain  a  complete  and 
smooth  information  flow  in  the  man/man  system.  This  applies  especially  when  the  two  have 
the  same  strong  personality,  or  each  one  is  used  to  different  thinking  patterns. 


A  real  objective  comparison  between  the  above  parodistic  description  of  three  different 
attempts  for  a  functional  1 i nkage/ i n tegra tion  of  two  "dissimilar  organisms"  to  a  good 
approximation  to  the  goal  of  "man-machine-symbiosis",  is  not  possible.  But  there  is  a 
short  list  of  things  worth  to  be  mentioned.  This  list  does  not  claim  to  be  complete  nor 
to  be  in  the  right  order  of  priority  by  importance/ vi tal  influence.  The  list  intends  only 
an  initiation  of  a  possible  extension  of  considerations  as  to  aspects,  completeness  of 
factors/disciplines,  and  the  degree  of  influence  they  might  have  upon  a  multidisciplinary 
system.  Therefore  it  could  be,  for  example,  a  very  important  result,  When  those  considerations 
about  the  process  ofthe  development  approach,  either  lead  to  the  exclusion  of  a  factor/discipline, 
or  only  to  the  attribution  of  minor  importance  because  of  no  or  minor  influence. 

I  am  certain  that  neither  myself, nor  some  one  else  will  have  a  complete  set  of  noteworthy 
topics  hereafter,  and  no  valid  answers  either.  In  order  to  get  some  more  substantiated 
methodology,  the  USAF  works  with  Other  services  since  1981  in  this  vaste  interdisciplinary 
area  (6),  and  plans  to  do  so  for  five  more  years. 

But  we  all  know  the  topics  exist  and  good  answers,  as  to  the  degree  of  its  vital  influence, 
are  very  important,  because  they  form  the  prerequisite  for  good  software,  which  we  despe- 
rately  need!  We  urgently  have  to  catch  up  with  the  increasing  performance  potential  of  the 
hardware  developed,  for  its  full  and  appropriate  use!  The  paramount  hardware  potential 
makes  only  sense  when  the  software  gap  will  be  closed  soon  and  firmly. 

The  before-mentioned  sketches  of  cockpit  types  have  -besides  their  differences-  several 
things  in  common: 

-  they  all  put  their  main  emphasis/priorities  on  different  factors  out  of  the  interdiscipli¬ 
nary  multitude  of  disciplines  and  their  parameters,  their  mutual  interaction  and  the 
resulting  effects. 

-  they  all  have  different  guidelines  &  criteria  for  the  concept  and  for  the  assessment  of 
the  effectiveness.  Objectively,  they  have  very  little  in  common  -exept  some  similar 
instruments  and  shortcomings. 

-  they  all  demand  more  or  less  a  different  mixture  of  work  overload  from  the  pilot  at 
critical  times/'phases  of  the  mission. (see  page  4,  last  para.) 

-  the  hardbooks  for  the  crew  contain  all  but  brief  &  clear  instructions  for  the  proper  use 
of  the  system  in  the  different  mission  phases.  Mistakes/"human  errors"  are  preprogrammed. 


-  none  of  the  cockpits  represents  a  good  possible  approximation  to  a  fully  conducted 
attempt  of  an  interdisciplinary  approach,  taking  for  example  the  human  member  fully 
as  a  complementary  part  of  the  total  system,  performing  only  in  the  functions/roles 
in  which  he  excels,  problem-solving/decision  making,  e.g. 

The  human  member,  however,  is  mainly  required  to  struggle  in  a  double  role: 

-  compensate  for  the  lack  of  proper  data/information  processing  &  integration 

-  cope  with  a  collection  of  complex  activities  which  were  not  understood  well  enough 
to  automate 

In  both  roles  the  human  being  does  not  excel  ! 

-  Guidelines  S  criteria  with  even  identical  phrasing,  but  written  by  different  people, 
are,  when  applied  to  different  cockpits,  not  comparable,  because  they  use  different 
definitions,  different  priorities  and  they  are  measured  by  different  methods. 

-  The  usually  dictated  requirement  for  empl oyment  of  existing  hardware -whether  airborne  or 
not-  predetermines  once  and  for  all  the  avionics  architec-ture,  multiplies  the  techni¬ 
cal  interface  problem,  dictates  one  or  more  computer  languages,  and  some  other  vital 
performance  reductions,  as  compared  to  the  technical  and  budgetary  possibilities. 

The  commonalities  list,  in  reality,  is  much  longer!  It  is  to  be  hoped,  however,  that  this 
type  of  commonality  will  not  become  a  kind  of  STANAG-status . 

A  good  reason  to  believe  in  a  different  commonality  are  the  first  signs,  which  allow  to 
believe  that  some  flying  machines  seem  tentatively  to  help  finding  a  better  understanding 
of  the  necessary  elements  &  their  interrelation  for  a  good  approach  to  the  functional  inte 
gration. 


2.1  New  aircraft  &  new  integration  Ap  proaches 


a . )  Hardware 

One  of  the  best  known  aircraft,  where  a  consequent  functional  integration  has  been 
attempted  by  means  of  digital  avionics, is  the  F-18.  In  this  aircraft, one  of  the  symptoms 
for  non-integration, a  high  number  of  dedicated  indicators/displays, has  been  reduced 
significantly  as  shown  in  Fig.  2. 

As  to  the  corresponding  quantity  of  controls  &  switches, a  figure  to  be  put  in  Fig.  1 
is  not  known  to  the  author  of  this  paper.  There  is  good  reason  to  believe  that  the 
number  of  dedicated  switches  &  controls  has  been  reduced  also  by  means  of  integration 
and  automation  of  functions. 

No  one  can  say,  how  far  away  the  F-18  is  from  a  possible  optimum.  It  sure  is  a  big  step 
in  the  right  direction.  Other  aircraft  development  with/and  integrated  digital  avionics 
retrofits  are  under  way.  A  comparison  of  the  different  approaches  is  not  yet  possible, 
because  either  the  aircraft  with  their  avionics  are  still  in  the  development  phase  or 
the  retrofit  kit  has  not  yet  been  adapted  to  the  aircraft.  Other  various  reasons  do 
also  exist. 

It  should  be  stressed  here,  that  the  revolutionary  phase  we  are  presently  in,  is  marked 
by  the  search  for  the  best  way  to  cope  with  the  paramount  potential  of  the  new  electronics. 
It  should  also  be  stressed  that  an  increasing  percentage  of  the  people  who  have  to  deal 
with  its  unexpected  possibilities  become  aware  of  the  miraculous  nature  of  this  dangerous 

toy,  and  its  problems.  The  euphoric  phase  is  over.  Assuming  that  several  different  aircraft 
with  di f ferent avionic/man  integrations  are  ready  for  assessment  &  evaluation,  the  comparison  will  remain 
impossible.  One  simple  reason  prevents  a  valid  comparison:  the  lack  of  common  yardsticks/criteria 
and  methods  to  measure, especially  for  systems  effectiveness  of  military  aircraft. 
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b. )  New  theoretical  approaches  supported  by  experiments/practice 

In  the  last  paragraph,  this  paper  will  help  to  initiate  discussions  for  the  preparation  of 
such  criteria  which  will  assist  to  improve  the  quality  of  a  functional  integration  by  m eans 
of  appropriate  development  priorities/objectives/interrelations  as  well  as  to  make  these 
measurable,  and  thereby  more  objectively  comparable. 

In  addition  to  the  direct  development  of  hardware  with  the  appropriate  new  kind  of  software, 
two  projects  are  in  progress  and  seem  promising  regarding  future  approaches  for  the  opti¬ 
mization  of  systems  effectiveness. 

-  Reference  2  describes  a  combination  of  Top  Down  &  Bottom  Up  approaches  actually  worked  on 
in  the  US-Navy  to  develop  Decision  Aids  for  multi-crew  aircraft  such  as  submarine  hunters, 
sea  patrols  etc.  This  activity  is  part  of  a  DAS  program  (Decision  Augmentation  Systems). 

The  title  (The  intelligent  use  of  intelligent  systems....)  indicates  the  direction  where 
it  comes  from:  The  computer  people  corner,  aiming  at  the  support  of  crew  members  who  have 
to  process  a  large  amount  of  information  and  data,  whose  source  is  a  multitude  of  dedica¬ 
ted  instruments,  sensors,  subsystem  outputs  .control  position  or  force  and  other  crew 
members.  They  aim  to  alleviate  the  critical  workload  of  TACCO's  &  other  crew  members. 

Direct  functional  action  like  automation  of  trajectory/attitude  control,  target  tracking, 
fire  control,  weapon  release  or  others  seems  not  to  be  intended  within  the  frame  of  this 
approach.  This  limitation  seems  to  exclude  the  physical  part  of  the  symbiotic  partner, 
the  man,  as  well  as  hydraulics,  electrical  drive,  propulsion . 

The  reason  that  makes  this  approach  promising  for  the  mental  part  of  the  total  system,  is 
the  practice-oriented  methodology  of  the  Systematic  Software  Engineering  process  which 
attempts  to  come  close  to  a  complementary/symbiotic  work-type  of  both  man's  brain  and 
computer.  In  addition,  a  high  degree  of  realism  seems  to  be  assured  by  taking  into  account 
right  from  the  beginning  existing  hardware  facts  and  human  perception  &  processing 
capabi 1 i ties .During  the  combined  process  of  Top  Down  &  Bottom  Up  approach,  the  permanent 
reference  to  reality  is  maintained  by  means  of  practical  tests. 

-  Reference  6  to  a  high  degree  is  a  TRI-Ssrvice  activity  which  began  in  summer  1981  where 
USAF  is  the  lead  service.  This  program,  with  the  objective  to  develop  a  series  of  speci¬ 
fications  and  guidelines  as  to  what  functions  should  be  automated  and  integrated  to  an 
appropriate  kind  and  degree,  comes  obviously  from  the  practical  users  corner.  It  brings 
about  the  realities  of  man's  inherent  shortcomings  in  using  sophisticated  systems  .especially 
in  critical  mission  phases.  The  basic  information  herefore  is  gained  by  means  of  a  syste¬ 
matic  interview  of  a  large  group  of  all  kinds  of  pilots.  A  methodology  is  than  derived 
from  this  data  bas i s ,wri tten  down  in  a  report  of  the  National  Academy  of  Sciences. 

This  report  shows  a  scheme  to  the  air  force  which  it  can  use  to  look  at  its  programs.  A 
five  year  work  has  begun  to  develop  and  substantiate  the  above  mentioned  series  of  speci¬ 
fications  and  guidelines.  This  work  is  oriented  towards  the  assessment  of  aircraft  control 
functions  to  determine  the  order  in  which  functions  should  be  automated  and  subsequently 
integrated  with  other  functions. 

This  program  is  a  very  promising  complement  to  the  approach  of  Reference  2,  because  it 
seems  to  bring  about  most  of  the  non-technical  elements  which  are  necessary  for  the  functio¬ 
nal  integration  of  man  &  machine.  It  is  a  kind  of  systematic  six  step  process  that  intro¬ 
duces  the  non-technical  factors,  some  of  which  are  to  be  derived  from  the  di fferent  mission 
phases  in  the  combat  theatre.  Some  others  stem  from  the  variation  of  human  factors  during 
the  mission  and  deal  with  flight  control,  autopilot,  target  sensing  &  acquisition,  navi¬ 
gation,  propulsion  control,  external  data  input,  crew  station,  threat  warning  &  counter¬ 
measures,  weapons  delivery/fire  control,  fuel  management,  malfunction  warning . 
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It  will  enable  the  developer  of  functionally  integrated  avionics  to  write  a  realistic 
interdisciplinary  Functional  Specification  which  is  of  fundamental  importance  ! 

The  attempted  mental  symbiosis  of  Reference  2  seems  to  be  restricted  to  brain  &  computer.  A 
combination  of  the  two  approaches  (Ref. 2  plus  Ref. 6)  encompasses  the  whole  man  and  thewhole 
aircraft  to  a  systems  entity.  This  is  what  I  mean  with  the  parable  of  the  "man-horse-sym¬ 
biosis",  where  both  are  functionally  integrated  with  each  other  during  a  ride,  by  means  of  a 
perfect  interface.  The  information  fed  through  this  interface  is  a  minimum  of  touch,  word 
and  tender  pull  of  bridle,  in  the  direction  from  man  to  horse.  The  information  from  the 
horse  to  the  man  is  mainly  fed  by  its  movements  (direction  &  speed  of  run..Jand,  of 
course,  by  the  voice  and  its  breath  too. 

All  other  functions  of  the  horse  are  automated  and  integrated.  The  rider  does  not  monitor 
data,  such  as  temperature,  blood  pressure,  heart  beat . 

His  workload  is  not  only  reduced  (like  everybody  requires),  but  minimized,  and  therefore  his 
perception,  processing  and  decision  potential  is  free  for  the  mission! 


3.  Draft  Proposal:  Guidelines  &  Criteria 


As  a  conclusion  of  the  above  mentioned  description  of  interrelations  between  the  different 
technical,  military,  geographical,  seasonal,  tactical  and  human  factors,  a  radical  change 
in  thinking  is  dictated.  Old  and  current  thinking  patterns  -without  any  serious  considera¬ 
tion  about  their  applicability-  will  restrain  the  necessary  interdisciplinary  span  of  the 
approach,  and  will  prevent/ reduce  the  possible  progress  toward  the  potentially  significant 
increase  in  systems  effectiveness. 

An  unconventional  and  independent  thinking  is  necessary  and  shall  cover  aspects  such  as: 

-  extension  from  a  limited  subsystem  thinking  and  acting  to  overall  systems  functional 
interrelation  thinking. 

inclusion  of  the  human  link  functions  (including  integration)  and  characteristics  in 
the  overall  functional  analysis  and  specification  of  the  total  system,  before  assig¬ 
ning  priorities  to  the  automation  of  functions. 

aspect  change  of  the  machine-oriented  operator-role  of  man,  to  the  man-oriented  tool/ 
support-role  of  the  technical  means  (hardware  and  software) 

strict  matching  of  subsystem  thinking  within  the  frame  of  the  total  system,  in  order  to 
avoid  mutual  "retrofit  adaptation",  due  to  isolated  subsystem  development. 

According  to  the  above  man-horse-parabe 1  ,  and  without  any  possibility  of  proving  it  at 
this  time,  the  author  would  like  to  postulate  that  the  pilots/crews  workload  not  only  has 
to  be  reduced  but  minimized  !  Thi s  postulation  is  additionally  supported  by  pilots  experi¬ 
ence  according  to  Reference  1.  Incidentally,  the  author  has  some  20  years  of  flying  and 
flight  test  experience  too. 

The  following  Guidelines  &  Criteria  are  established  with  the  minimizing-premise  in  mind, 
for  military  manned  aircraft. They  apply  primarily  to  single  or  two  crew  aircraft  which 
operate  mainly  in  or  close  to  the  co'ubat  theatre,  and  which  must  perform  many  tactical 
maneuvers.  They  contain  keywords  and  determine  thereby  the  criteria  within  the  concept  for 
the  desiyn  process  and  the  assessment  thereof. 


a. )  G  u  i  d  e  1  i 


n  e  s 


1.  The  man-machine  interface  schall  be  considered  a  highly  critical  item  within  the  over¬ 
all  systems  loops.  Accordingly  this  interface  shall  be  given  the  appropriate  high  pri¬ 
ority  against  all  other  factors  unless  these  taken  together  are  of  vital  importance 
and  can  be  justified  using  criteria  yet  to  be  determined. 


- - -  - - .... - 
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2.  Compromises  in  sub-  and  total  systems  layout  and  practical  design  should  be  confined 

to  the  area  outside  the  display  &  control  system  in  the  cockpit,  unless  criteria  yet  to 
be  determined  justify  digression. 

3.  By  no  means  everything  technically  possible  shall  be  made  or  done  within  the  cockpit. 
This  applies  to  the  presentation  of  visual,  acoustic  or  haptic  information  and  combi¬ 
nations  thereof  as  well  as  to  the  provision  of  any  kind  of  control  (switches,  levers, 
knobs,  keyboards  etc.),  which  requires  avoidable  control  action. 

4.  The  amount  and  the  kind  of  information  and  control  functions  to  be  handled  by  the  pilot/ 
aircrew  shall  be  limited  to  that,  which 

a)  cannot  be  improved  by  automation 

b)  is  absolutely  required  for  operational  purpose 

For  any  additional  information  and  control  capability,  the  need  must  be  justified. 

5.  By  no  means,  systems  having  possibly  a  cockpit  interface  shall  be  specified  and  develo¬ 
ped  in  isolation,  without  allowing  to  be  controlled  for  overall  cockpit  layout  and 
integrated  functional  fit. 

6.  In  order  to  achieve  the  goal  of  an  optimum  in  total  systems  functional  integration,  incl  uding 
its  human  member,  interdisciplinary  thinking  and  working  is  mandatory  throughout  the 
subsystems  design  and  development  process.  This  is  to  be  ensured  by  appropriate 
managemant  procedures  and  measures. 

b. )  Criteria 

1.  Consideration  of  pilot  performance  characteristics. 

Pilot  performance  is  characterized  by: 

-  high  variability  of  mental  (information)  processing  and  decision  making  capabilities 

-  poor  monitor  and  watchkeeper  capability 

-  high  variability,  however  limited  speed  of  motor-capabilities 

-  susceptibility  to  sequential  errors  where  a  step  is  left  out  of  a  procedure  and 
capture  errors  where  a  familiar  procedure  is  substituted  for  an  intended  new 
procedure. 

-  moderate  performance  in  serial  processing  -A  human’s  attention  to  two  or  more  activi¬ 
ties  requires  rapid  switching  between  the  tasks. 

-  poor  perception  &  processing  capability  for  high  information  volume  and  rate 

-  poor  processing  rate  -Two  events  occurring  closer  together  than  0.1  sec.  generally 
will  be  perceived  as  a  single  event. 

-  little  "reconfiguration"  capability 

Note:  All  above  mentioned  capabilities  will  suffer  a  considerable  degradation  in  a 
hostile  and/or  emergency  environment! 

The  priorities  resulting  therefrom  are  to  be  accounted  for  in  trade-offs  performed! 

2.  Limitation  of  information  displayed  (or  somehow  given  to  the  pilot). 

All  cockpit  functions  and  correlations  thereof  shall  be  checked,  wether  their  automa¬ 
tion  would  be  advised,  in  order  to  reduce  the  amount  of  visual,  acoustic  and  haptic 
information  being  fed  trough  the  man-machine  interface  to  the  necessary  minimum.  Cri¬ 
teria  against  which  the  checking  shall  be  performed  are: 

-  feasibility 

-  pilot  workload  minimal  possible  in  a  combat  situation 

-  freedom  of  pilots  judgement/decision  within  systems  performance/maneuvres/actions 
in  any  mission  element 

3.  Limitation  of  all  kind  of  control  activities. 

All  input-  and/or  control  functions  shall  be  checked  whether  their  automation  would  be 
advised,  in  order  to  minimize  the  necessary  amount  of  manual  or  other  activities  to  be 
performed  by  the  human  member. 

Criteria  against  which  the  checking  shall  be  performed  are  the  same  as  in  2.  before. 

4.  Any  automated  information  covered  by  criterion  2.  may  be  provided  for  the  human  link 
whenever  it  serves  to  improve  his  judging  of  the  flight  or  combat  situation  in  order 


to  reduce  an  unnecessary  emergency  or  threat  risk. 

A  trade-off  shall  be  performed  between  the  degree  of  risk  reduction  achievable  and  the 
resulting  increase  in  the  pilot's  workload,  taking  criterion  1.  into  consideration. 

5.  Any  input  and/or  control  activity  that  might  be  automated  according  to  criterion  3. 
may  be  imposed  on  the  human  member,  whenever  an  emergency  or  threat  can  be  covered 
therewith  in  the  vital  sense,  which  could  not  be  covered  by  technical  means. 

A  trade-off  shall  be  performed  between  the  increased  probability  of  overcoming  the 
flight  safety  or  threat  risk  against  the  increase  of  pilot  workload,  taking  into  con¬ 
sideration  criterion  1. 

The  above  proposed  Guidelines  &  Criteria  are  intended  to  offer  a  basis  of  discussion  for 
the  development  of  common  Guidelines  &  Criteria  within  NATO.  They  are  also  intended  tooffer 
some  aspects  and  means  which  might  help  to  find  better  judgement  as  to  the  evaluation  of 
designs,  design  approaches  and  with  respect  to  its  kind  of  techniques  used  to  achieve  the 
Qtet  1 1  i,t  **?<.?*  ♦  tU)  n.fgU  l.  tlldUttr  U  ttol? 

quality  of  the  key  design  decisions  which  must  be  made  at  all  stages  of  the  development 
process . 


4.  CONCLUS  1QN 

A  main  effort  of4$his  paper  4s  %q>advocate5.a  maximum  of  interdisciplinary  work.  Accordingly 
emphasis  is  put  on  the  need,  for  better  functional  integration  of  the  human  member  of  the 
system,  and/Tby  minimizing^  is  workload,  instead  of  only  reducingyin  some  areas.  Tlrerefore 
the  author  proposes  to  combine  .the  two  approaches  of  Ref. 2  and  Ref. 6,  rough-ly  a  combination 
of 'the  mental  and  the  physical  part  to  make  maximum  use  of  the  human  member^  unsurpassed 
capabilities.  He  is  still  the  main  limiting  factor  for  the  system  effectiveness,  due  to  the 
inappropriate  interface/functional  integration  with  the  system's  technical  means. 


Although  this  paper  does  present  a  -of^systemati c  approach  by  means  of  the  above  combi 
nation,  the  author  has  no  illusion  that  the  development  of  such  an  integrated  airborne 


system  can  be  properly  engineered  now  to  the  possible  optimum.  Such  a  work  still  relies 

,  .  c 

more  on  'art"  than  engineering!  Maybe  this  paper  is  at  least  a  contribution  to  a  more  reali¬ 
stic  evaluation  of  the  effectiveness  of  man-machine  interfaces. 
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SUMMARY 

The  Advanced  Aircraft  Armament  System  (AAAS)  was  originally  chartered  to  improve  armament  equipment 
performance,  support,  and  interoperability.  Because  of  funding  constraints  the  AAAS  Program  has  been  increasingly 
directed  to  development  of  air  armament  interface  standards  and  technology,  while  advanced  concept  development 
of  suspension  release  and  stores  management  equipment  has  been  de-emphasized.iThe  current  program  concentrates 
on  supporting  the  Joint  Navy/Air  Force  Aircraft  Armament  Interoperable  Interface  Program  whose  task  is 
development  of  MIL-STD-1760  (Aircraft  Electrical  Interconnection  System)  and  associated  guidelines  for  successful 
application. 

'^Since  the  advanced  concepts  which  were  to  be  originally  developed  are  a  more  appropriate  subject  for  this  paper, 
the  context  of  the  discussion  is  the  program  prior  to  the  redirection.  The  Fleet  needs  and  deficiencies  which  provided 
the  requirements  for  the  concept  effort  are  briefly  outlined,  the  objectives  and  goals  are  detailed,  and  the  approach 
to  achieve  mission  flexibility  and  performance  improvements  at  reduced  ownership  costs  is  discussed.  A  key  aspect  of 
the  approach  is  development  of  generic  designs  which  capitalize  on  cost  and  growth  advantages  of  standards  while 
allowing  incorporation  of  advancing  technology.  A —? 


INTRODUCTION 

The  Advanced  Aircraft  Armament  System  (AAAS)  Program  began  at  the  Naval  Weapons  Center  in  October  1978. 
Original  objectives  included  development  of  advanced  stores  management  system  (ASMS)  and  suspension  release 
equipment  (S&RE) .  Initial  program  goals  also  comprised  armament  performance  and  supportability  improvement  as 
Mul  fit  lulutf  ftfirudl -mnepat'  Inhere^  Ltnr*<U  p&gMPi  Im  been  natrtej  Vt  MTfhMi  tta 

interoperable  interface  standards  and  design  guidelines  for  successful  future  SMS  implementations  on  fighter  and 
attack  "kircraft.  These  interface  standards  are  being  developed  under  the  joint  Aircraft  Armament  Interoperable 
Interface  (AAII)  Program  in  cooperation  with  the  Air  Force  Armament  Laboratory,  Eglin  AFB,  Florida.  The 
standards  are  incorporated  as  physical,  electrical,  and  logical  portions  of  the  MIL-STD-1760.  An  electrical  signal  set 
was  released  1  July  1981,  and  Notice  1  is  soon  to  be  published  documenting  intermateability  characteristics  of  the 
connector  portions  (physical)  of  the  standard. 

This  paper  will  not  discuss  the  AAAS  Program  as  now  chartered,  but  will  cover  those  original  stores  management 
technology  objectives  and  approaches  which  were  to  be  accomplished  and  which  relate  to  avionics  concept  growth. 

1  .lor  M  *n  g  mrH  I  ;;'i  v  '.•!I',|«A  1  I  .1  v‘  n'  '  wv.  1  ,st  m  ■  o  "•> 

functions  which  include  monitoring,  initializing  and  controlling  stores  and  the  associated  suspension  release 
equipment.  The  SMS  provides  fault  assessment,  mode  regression  and  jettison  backup  capabilities.  In  the  past,  SMSs 
have  been  developed  on  an  aircraft-by-aircraft  basis.  The  older  SMSs  are  generally  hardwired,  not  integrated,  not 
automated,  and  they  embody  outmoded  technology.  Newer  SMSs  reflect  more  current  technologies  and  far  more 
effective  integration  and  automation.  However,  it  remains  a  fact  that  even  modern  SMSs  are  tailored  to  support  the 
speciflc  scores  ,!'t  an14  unique  loadout  configurations  of  individual  aircraft  types. 

The  discussion  which  follows  will  explain  the  source  of  requirements  for  improving  stores  management  designs,  the 
resulting  objectives,  and  finally  some  of  the  useful  concepts  which  have  emerged.  The  program  was  active  for 
lhae*  Mm  MferutUor  with  fte^t  -jnt  ptofkmet, « 

area  reports  and  a  contract  statement  of  work  and  specification.  Currently,  two  contracts  are  in  place  and  system 
analyses  have  begun  that  will  result  in  design  specifications  for  an  advanced  generic  system.  During  initiation  of  the 
contracts,  an  attempt  was  made  to  maintain  an  awareness  of  the  main  thrusts  in  avionics  design  and  integration. 
Some  of  the  concepts  evolved  during  performance  of  the  contracts  may  have  application  to  avionics  integration  or  at 
least  may  be  useful  in  defining  the  evolution  of  stores  management  for  follow-on  avionics  systems  effort. 

SYSTEM  DEFICIENCIES  AND  REQUIREMENTS 

In  the  seventies,  a  number  of  studies  were  initiated  to  identify  those  functional  interfaces  between  a  ship's  company, 
air  armament  equipment,  and  standard  operating  procedures  which  impact  mission  effectiveness.  The  proliferation 
jj  trimmer.*  eqaipiuw.'  w*  lietxrH.mreC  'c  U  « *Ag t&Vmf  rnm-.i  <J)  cpe.a'v id.  «r.<i  v*p <m<! 

it  was  recommended  that  aircraft  armament  system  interfaces  be  controlled  in  the  future  to  minimize  such 
proliferation. 

The  initial  studies  also  identified  characteristics  and  functions  of  the  mission  cycle  which  were  deficient  in  capability 
and  required  performance  improvement.  Many  of  the  deficiencies,  such  as  ack  of  availability  and/or  selection  in 
weapon  systems,  impacted  numerous  elements  of  the  larger  Navy  Fleet  missions;  these  deficiencies  also  were  directly 
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influenced  by  aircraft  stores  management  system  capability.  The  relationship  of  these  needs  and  deficiencies  to  the 
carrier  aircraft  mission  cycle  is  diagramed  in  Figure  1.  Some  larger  needs,  in  terms  of  ownership  cost  impacts,  were 

u.-  jviulc  l  Witt,  tlic  .-  Ij  l'i  ,  tr  CXCeiliS  ihuuUlf  atj  ll.T  nt  SCf-rtv  life  v  t  .  i. artel'idt  V/J  ftCuiiligulAti-iI,  a. .  . 

modification  to  accept  new  weapons.  With  current  aircraft  and  avionic  designs,  this  capability  is  made  extremely 
costly  and  limited  by  the  uniqueness  of  the  large  number  of  -armament  interfaces  concerned.  An  illustration  of  this 
interface  proliferation  is  snown  m  Figure  2.  I  tie  cost  ot  new  weapon  installation  in  older  aircratt  is  so  large  ana 
carries  such  large  support  implications  that  deployment  of  new  weapons  is  severely  limited. 

A  further  complicating  factor  has  been  the  growth  in  complexity  and  number  of  weapon  types  required  in  modern 
warfare.  Figure  3  shows  this  growth  in  terms  of  numbers  of  pins  at  the  interface  and  the  large  variation  in  signal 
types  between  weapons.  A  major  objective  of  the  AAII  Program  has  been  to  develop  MIL-STD-1760  (the  aircraft 
electrical  interconnection  system  standard),  to  control  interface  complexity,  and  to  encourage  growth  of  digital 
systems  in  missiles.  However,  to  make  future  aircraft,  whether  new  or  updated,  capable  of  low  cost  armament 
growth  without  major  avionic  and  control  system  impacts,  stores  management  systems  must  be  designed  with 
absorbent  hardware  and  software  architectures. 

One  driving  requirement  then  for  the  AAAS  and  AAII  efforts  is  to  improve  interoperability  among  aircraft  weapon 
systems.  Weapon  system  interoperability,  as  it  applies  to  military  aircraft,  describes  those  capabilities  of  the  system 
lhal  feUoa  Go  be  used  ir  fk.nritk  a  to  j  rcUx  ki  xny  4  lull  Vyi'VKii  Siii't-ra*  Vi  tt*J?I- Hy 

capitalization  cost  effective.  Modern  military  aircraft  and  weapons  are  products  of  the  best  designs  presented  at  the 
time  of  commitment  to  production  and,  as  such,  are  point  design  systems.  However,  rapid  technological  advances 
and  changing  enemy  capabilities  frequently  render  entire  weapon  systems  obsolete — in  many  cases  the  day  the  new 
system  becomes  operational.  In  order  to  counter  the  effects  of  obsolescense,  aircraft  and  weepon  systems  must  be 
continually  upgraded  by  expensive  modifications  involving  installations  of  new  technology  subsystems  and 
assemblies.  This  very  high  modification  cost  and  associated  time  constraint  is  a  major  problem  again  resulting  in 
limited  initial  procurements,  restricted  deployment  of  new  capabilities,  and  resulting  high  unit  costs. 

Recently  the  Department  of  Defense  and  Congress  has  taken  a  position  to  encourage  the  use  of  standards  in  weapon 
systems.  A  major  obstruction  to  interoperaOiiity  in  aircraft  weapon  systems  is  non-standard  aircraft-to-weapon 
(store)  and  store-to-aircraft  interfaces.  Other  interfaces  such  as  the  weapon  to  avionics,  through  the  stores 
management  subsystem,  also  obstruct  interoperability  and  growth. 

CuiuplcAity  and  yiuliTeiatiuu  nave  biuuj^hl  othei  del ivi elicits  aiid  needs  svbiid,  iTitiuence  STi  ICS  nitniagcflietit  and 
avionics  systems.  Most  of  these  involve  performance,  support,  or  cost.  The  more  dramatic  include  pilot  workload 
and  training  increases  and  pilot  task  complexity  growth.  For  the  ground  crew,  the  task  complexity  growth  is  even 
greater  and  the  ettects  appear  in  downed  aircratt  and  lower  aircratt  avaiiamity.  io  reacn  acceptaDte  levels  ot 
readiness  and  capability  at  affordable  expenditures  requires  improvements  in  performance  and  judicious  use  of 
H  ,/NiAidt  II  Ha  iiiitufi  uni'UEUrUi  <jMwra.  TIUl  bl  uunitty  ihr  pytHum  »"d  f*i  HignaSin" 

into  aircraft  and  weapon  systems  of  the  future. 


-  FLEET  OPERATIONS/MISSION  CYCLE 


CONFIGURE 


OPERATIONS 
PLANNING  I  AIRCRAFT 
PREPARATION 


CONFIGURE 

SMS 


IN-FLIGHT 
PREP  ANO 
MS  TEST 


OR 

JETTMON 


RETURN 


RECYCLE 


WEAPON/AIRCRAFT  INTEROPERABILITY 


IMPROVEO  OELIVERY— ►  IMPROVE 0  STORE  FLIGHT  LIFE 


FLEXIBILITY  IN  - 

WEAPON  SELECTION 


.  MINIMUM  RECONFIGURATION 


■  REOUCEO  CREW  WORKLGAO  • 


SELECT  ALTERNATE  - 
STORE  OPTIONS 


-  RSAOINESS  MPR9VEMENTS 


NON- 

STANOARO 

BARE 

COMPLEX 

LABOR- 

NON¬ 

AUTOMATIC 

LACK 

RESTRICTIVE 

LACK 

EXCESSIVE 

ANO 

INTENSIVE 

HAROWARE 

OF 

OELIVERY 

OF 

SB  RE 

STATIONS 

FUNCTION 

FUNCTION 

BIT 

CONDITIONS 

FLEXIBILITY 

MAINTENANCE 

Figure  1.  Carrier  aircraft  mission  cycle  needs  and  deficiencies 
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AAAS  APPROACH 

In  response  to  these  needs  the  overall  objective  of  the  AAAS  Program  became  not  only  standardization  of  weapon-to- 
aircraft  interfaces  but  to  do  so  without  restricting  technology  and  design  improvement  growth.  This  required 
coordination  with  all  affected  groups  to  develop  interface  associated  equipment  design  guidelines  for  improved 
performance.  These  design  guidelines  would  also  include  standards  which  it  is  believed  would  halt  the  proliferation 
of  interfaces  and  help  in  achieving  low  cost  growth  and  support  objectives  (see  Figure  4).  Although  this  objective 
covered  suspension  and  release  equipment  this  paper  only  discusses  the  stores  management  equipment  and  briefly  the 
standard  interface. 


Figure  5  summarizes  the  major  AAAS  objective,  the  required  products,  and  lists  the  expected  benefits  and  approach. 
Besides  the  AAII  joint  program,  a  laboratory  tool  was  necessary  to  investigate  options,  and  test  design  guidelines  and 
validate  standard  decisions.  The  ASMS  laboratory  proposed,  and  which  is  now  partially  constructed,  is  shown  in 
Figure  6.  This  lab  configuration  requires  the  development  of  future  store  and  aircraft  simulators  and  stimulators,  an 
advanced  stores  management  subsystem  of  a  generic  nature,  and  a  computerized  data  base  and  software  necessary  to 
drive  the  data  base. 

In  the  ASMS  laboratory,  coded  data  will  be  transmitted  over  twisted-wire  pair,  internal  time  division, 
comm  and/ response,  multiplex  data  buses  which  meet  MIL-STD-I553  requirements.  The  control/display  equipment 
will  employ  integrated  multifunction,  multicolor  displays  with  preprogramed  built-in-test  diagnostics  and  control 
options  through  s  dedicated  control  panel.  The  store  station  equipment  (SSE)  will  be  a  distributed  family  of 
programmable  microprocessors  which  code/decode  message  transmissions  and  process  messages  to  control  power 
switching  functions  and  communicate  with  interfacing  stores.  The  SSE  will  be  preprogrammable  to  be  compatible 
with  interoperable  carriage  and  mission  stores.  The  central  processing  unit  will  be  preprogramed  for  command  and 
control  of  appropriate  mission  scenarios  and  tactical  contingency  options. 

The  ASMS  laboratory  system  will  be  used  to  control  and  exercise  the  MIL-STD-1760  electrical  interoperable 
interfaces,  allow  development  and  assessment  of  future  Navy  aircraft  specifications  for  SMS,  and  validate  developed 
armament  implementations.  The  advanced  stores  management  laboratory  will  include  signal  control  equipment, 
displays  and  controls,  stole  station  equipment,  data  transfer  equipment,  and  stores  management  processor  software. 
Stores  management  subsystem  concepts  and  alternatives  to  be  validated  include:  digital  data  bus  architecture 
between  the  stores  management  processor,  store  station  equipment,  and  the  display  and  control  panel;  and  very  high 
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Figure  5.  AAAS  program  essential  characteristics. 


Figure  6.  Advanced  SMS  laboratory  for  the  study  of  interface  and  SMS  requirements 
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speed  integrated  microelectronic  devices/packaging  for  store  stations  in  adverse  environments.  The  ASMS  laboratory 
will  also  be  employed  to  evaluate  stores  management  equipment  architecture  optimized  for  reduced  crew  workload, 
AitopAvui  upuralluiKil  xksdbility  -oJ  aiwfc  utility,  jud  BuftfgJrt  degraded  *,.ajCL  op*a(kmufuiiuiJUJir^rt  IMI 
programmability  concerning  the  addition  of  future  weapons  to  an  aircraft  store  suite  with  minimum  cost  and  time 
will  also  be  studied  in  the  ASMS  laboratory. 

A  series  of  contracts  were  awarded  and  engineering  studies  conducted  to  define: 

(1)  the  signal,  states,  and  control  characteristics  of  future  projected  and  existing  weapon  systems, 

(2)  information  and  electrical  power  transfer  characteristics  across  the  weapon-to-aircraft  interface, 

(3)  obstructions  to  operability 

(4)  standardization  alternatives  as  a  function  of  several  system  characteristics, 

(5)  generic  SMS  and  laboratory  software  and  hardware  architecture  options,  and 

(6)  several  studies  relating  to  special  SMS  or  interface  system  problems. 

The  results  of  these  studies  were  used  to  generate  inputs  to  M1L-STD-1760,  to  prepare  the  ASMS  contract 
specification,  and  were  also  given  to  industry  bidd  'rs  as  background  in  bid  preparation.  In  order  that  the  joint 
interface  standards  and  SMS  design  guidelines  efi^.-ts  would  be  successful  and  provide  a  broader  search  for 
engineering  solutions,  two  contracts  were  awarded,  one  by  Navy  AAAS  and  another  by  Air  Force  AFATL  through 
the  Navy. 

Although  the  AAAS  development  efforts  are  not  complete,  some  emerging  concepts  may  be  of  interest  to  the  avionics 
community.  These  concepts  representing  only  a  portion  of  those  developed  will  be  discussed  in  the  next  section. 


CONCEPTS 

The  concepts  worthy  of  discussion  at  this  time  evolved  from  the  systems  analysis  efforts  directed  at  defining  and 
evaluating  standardization  opportunities,  rationales  and  requirements.  Valuable  concepts  were  also  gained  from  the 
ASMS  contractors  bid  responses  to  the  SMS  engineering  functional  requirements  developed  during  1979-1981.  They 
will  be  briefly  illustrated  and  discussed  in  the  following  order: 

Store-to-aircraft  standard  interconnection  system 

—  obstructions  to  operability 

—  operability  levels 

SMS  architectures 

—  multiple  buses  and  distributed  processing 

—  total  aircraft  data  network 

—  fiber  optic  application 

—  software  development  tools 

SMS  subsystem  standards 

—  data  transfer 

—  software 

—  digital  process  control 

—  briefing  entry  device 


STORE-TO-AIRCRAFT  INTERCONNECTION  SYSTEM  CONCEPTS 

The  development  of  criteria  for  assessing  interface  standards  effectiveness  and  selecting  standardization  alternatives 
for  MIL-STD-1760  resulted  in  concepts  which  may  have  application  at  other  aircraft  and  avionics  interfaces. 


Obstructions  to  Operability 

The  first  of  these  concepts  is  the  definition  and  decomposition  to  design  level  of  the  characteristics  which  are 
preventing  or  obstructing  operability  at  the  interface.  Although  this  appears  at  first  glance  to  be  normal  design 
analysis,  its  rigor  makes  possible  the  development  of  operability  levels  for  assistance  in  subsystem  integration  and 
standards  selection.  Six  of  the  nineteen  obstructions  to  operability  developed  for  MIL-STD-1760  are  decomposed  in 
Table  1  as  an  illustration  of  the  concept. 


Operability  Levels 

The  second  concept  is  the  technique  of  structuring  operability  levels  in  ranked  order  of  decreasing  system  impact  top 
to  bottom.  This  arrangement  allows  the  development  and  comparison  of  standardization  alternatives  for  various 
desired  integration  objectives  or  degrees  of  standardization. 


Table  1 

OBSTRUCTIONS  TO  OPERABILITY  CONCEPT 


Obstruction 

Underlying  Deficiencies  at  Design  Level 

1.  Failure  af  connectors  ta  mate 
at  the  interface 

•  Different  number  af  connectors  ot  the  interface 

•  Different  location,  arientotion,  ond  layout  af  connectors 
with  respect  ta  the  mechonical  mounting  interface 

•  Different  connector  shell  mechanical  types  (lacking  mechanism, 
etc.) 

•  Different  connector  shell  size 

•  Different  connector  insert  details 

Number  ond  size/type  af  pins 

Arrangement  af  pins  of  each  size/type 
-  Pin  connection  mechonism  details 

•  Different  convention  regarding  which  side  of  interfoce  has 
which  sex  af  connector 

•  Different  connector  materials  (electrolytic  compatibility, 
etc.) 

•  Different  connector  shielding  and  grounding  provisions 

2.  Lack  af  circuit  continuity 
(ar  proper  circuit  termi¬ 
nation)  at  the  interface 

•  Different  number  ond  definition  of  circuits  at  the  interface 

•  Different  ollacation  af  circuits  ta  various  connectors  (in 
o  multi-connector  interface) 

•  Different  ollacation  af  circuits  ta  connector  pins  (or  other 
interfaces  such  as  for  fiber -optics  circuits)  within  a  given 
connector 

•  Different  termination  of  circuits  that  do  not  pass  across 
the  interface 

3.  Circuit  incompatibility  on 
the  twa  sides  af  the  interface 

•  Different  impedance  and/or  transfer  function  character¬ 
istics  ot  the  various  circuits 

•  Different  circuit  bandwidths  on  two  sides  af  the  interface 

•  Different  circuit  naise  immunity  on  twa  sides  of  the 
interface 

•  Different  circuit  current  capability  on  two  sides  of  the 
interface 

•  Different  ciicuit  fault  protection  provisions  on  two  sides  of  the 
interface 

4.  Waveform  incampotibiiity  on  o 
given  circuit 

•  Different  maximum  amplitude  an  two  sides  af  the 
interface 

•  Different  basic  ar  clock  frequency  an  two  sides  af  the 
interface 

•  Different  waveshape  on  two  sides  af  the  interface 

•  Different  signal  stability  an  two  sides  of  the  interface 

•  Different  signal  spectra!  distribution  an  two  sides  of  the 
interface 

5.  Waveform  incampotibiiity  between 
two  or  more  given  circuits 

•  Different  phase  relationships  between  given  circuits 
on  twa  sides  of  interfoce 

•  Different  polarity  relationships  between  given 
circuits  on  two  sides  of  interfoce 

4.  Incompatibility  af  network 
architectures 

•  Hierarchy  af  buses  different  on  twa  sides  af  interfoce 

•  Location  of  intelligent  terminols/bus  controllers 
different  an  two  sides  of  interfoce 

•  Distribution  af  intelligence  ta  subsystems  different 
on  twa  sides  af  interface 

■~»a- 1  VaSa-M  >i.rir-y 
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The  interface  system  described  in  Table  2  may  be  standardized  at  different  levels,  i.e.,  lor  a  given  aircraft-store 
pair,  the  boundary  between  the  standardized  portion  of  the  interface  and  the  unique  portion  of  the  interface  may  be 
Jtiw n  JW  Jilifinj  Bur  ta  MuOfKUtif  tatuka  alj  patzj  i.uilig  ijtlr  taiwftfce  iaSgU  fcitL  Hu*  ULltut 

degree  of  standardization;  however,  the  extent  of  the  interface  that  must  be  designed  uniquely  may  be  different  for 
each  individual  pair.  The  overall  impact  of  the  interface  specification  on  the  aircraft-store  systems,  therefore, 
depends  on  both  the  standardized  portion  and  the  individual  custom  portions. 

From  the  lowest  level  to  the  topmost  level,  each  succeeding  level  of  operability  builds  upon  the  previous  level  to 
provide  an  increasing  degree  of  standardization.  The  complete  set  provides  complete  electrical  operability  between 
aircraft  and  stores. 

Clearly,  standardization  at  increasing  levels  will  provide  greater  degrees  of  operability  and  interoperability. 
However,  the  higher  levels  of  standardization  may  impose  increased  system  costs  or  undesirable  system  constraints. 
Therefore,  it  is  necessary  to  evaluate  succeeding  levels  of  standardization  to  determine  the  benefits  and  identify 
associated  costs  and  risks. 


Table  2 

OPERABILITY  LEVELS  CONCEPT 


Levels  af  Operability 


•  Information  interpretation  management 
Information  interpretation  (26) 
Information  sequencing  (25) 
Resource  management  (24) 
Network  management  (23) 
Information  synchronization  (22) 


•  Information  content 

Data  precision/resolution/ 
scaling  (21) 

Data  encoding  (20) 

Error  management  (19) _ 

•  Information  transport  management 

Standardized  messages  (18) 

Information  formatting  (17) 

Flaw  control  (16) 

Fault  detection  and  correction 
procedures  (1 5) _ 

•  Message  management 

Messaging  structure  (14) 

-  Error  detection,  resynchronization, 

error  correction  procedures  (13) _ 

•  Multiplexing  aspects 

Data  definitions/framing  features  (12) 
Network  control  procedures  (II) 
Timing  and  synchronization 
features  (1 0) 

Addressing  features  (9) 

Multiplexing  scheme  (8) _ 

•  Assignment  af  signals  ta  circuits  (7) _ 

Network  topological  features  (6) _ 

•  Signal  features 

On  a  given  circuit  (5) 

Between  two  ar  more  circuits  (4) 


•  Transmission  medium 

Circuit  physical  architecture 
features (3) 

Circuit  electrical  features  (2) 


•  Connector  mechanical  features  (I ) 


Standardization  Alternatives 


VII 


VI 


V 


IV 


II 


I 


VIII 


IX 
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SMS  ARCHITECTURES  CONCEPTS 


The  two  ASMS  contractors  initially  responded  to  the  contract  specifications  and  requirements  with  proposed 
architectural  configurations  which  indicate  a  direction  for  integration  with  other  avionics  systems. 

Multiple  Buses  and  Distributed  Processing 

Digital  data  bus  architectures  can  be  evaluated  and  selected  by  defining  and  developing  the  following  parameters: 
Information  transfer  redundancy  Efficiency  (quality) 


Information  latency 


Overhead  (burden) 


Throughput  (Bus  capacity) 

Because  system  data  latency  is  proportional  to  the  number  of  interconnected  buses  and  the  “inter  bus”  data  transfer 
rates,  the  bus  architecture  b^omes  a  key  area  for  careful  evaluation.  The  two  selected  contractors  for  the  Navy  and 
Air  Force  both  proposed  preferred  architectures  as  proposal  baseline  concepts.  Both  of  these,  Figures  7  and  8 
indicate  multiple  buses  are  desired  for  several  reasons.  A  key  reason  is  the  flexibility  and  redundancy  in  distributing 
the  digital  processing  made  possible  by  these  configurations.  How'ever,  the  tiering  or  layering  of  MIL-STD-1760 
standardized  interfaces  made  mandatory'  by  multiple  store  carriers  and  future  weapon  configurations  drives  toward 
multiple  buses  with  ■•‘indirdized  characteristics.  Experiments  will  be  necessary  to  verify  the  effects  on  key  system 
parameters. 
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Figure  7.  Contractor  A  baseline  SMS  configuration  architecture 
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Figure  8.  Contractor  B  baseline  SMS  configuration  architecture 


Total  Aircraft  Data  Network 

Many  different  digital  data  communication  “buses”  which  do  not  conform  to  MIL-STD-1553  are  used  on  current 
aircraft  systems.  The  diverse  system  architectures  and  interface  requirements  of  existing  aircraft  make  necessary  the 
provision  for  avionics  integration  modules  or  units,  individually  designed  to  adapt  the  SMS  to  the  aircraft  in  which 
it  is  used.  The  expected  functions  required  are  easily  discernable;  they  involve  the  common  methods  of  data  and 
control  transmittal.  The  functional  sizing,  A-to-D  converter  size,  number  of  DC  outputs,  word  size  of  non-MIL- 
STD-1553  buses,  etc.,  can  only  be  derived  from  the  specific  application.  Typically,  the  numerous,  dissimilar  I/O 
elements  each  have  their  own  timing  and  response  requirements. 

In  the  use  of  the  newer  system  designs,  consolidation,  sharing,  and  standardization  of  digital  buses  should  yield  large 
savings  from  reduced  systems  complexity.  Further,  if  the  whole  data  network  of  the  aircraft  could  be  controlled 
with  st'.iidards  to  produce  a  common  information  transmission  system  into  which  technologically  growing  avionic 
subsystems  could  be  exchanged,  updated  and  replaced  easily,  all  aspects  of  the  aircraft  mission  readiness,  and  life 
cycle  could  be  improved.  Again,  this  is  not  a  unique  concept  implied  by  SMS  efforts  alone  and  has  been  gaining 
favor  in  various  design  groups  around  the  country.  As  the  architectural  and  system  trade  studies  progress,  this  total 
aircraft  data  network  gathers  more  and  more  interest.  Figure  9  shows  how  armament  controls  data  bus  requirements 
could  serve  as  the  initial  source  for  integration  and  consolidation.  The  pilot  interfacing  with  the  aircraft  weapon 
system  during  a  mission,  typically  passes  inward  from  mission  and  Fleet  interfaces  and  actions,  thiough  aircraft 
systems  and  weapons  systems  interactions  to  the  final  weapon  release.  Common  functions  in  armament  controls 
leading  back  to  common  functions  in  weapon  system  support — leading  to  common  interfaces  with  other  aircraft  and 
mission  support  functions— making  possible  important  system  integrations  and  simplifications. 


Figure  9.  Pilot  interactions  with  avionics  progress  from  top  to  bottom 


Fiber  Optic  Application 

The  airborne  fiber  optic  studies  over  the  last  several  years  coupled  with  the  success  of  the  communications  industry 
in  applying  this  technology  has  peaked  the  interest  cf  system  designers.  The  advantages  are  numerous  and  the 
current  disadvantages  almost  as  numerous.  The  AAAS  intent  through  79,  ’80  and  ’81  was  to  attempt  the 
implementation  of  an  advanced  fiber  optic  SMS.  Fund  shortages  and  industry  evaluations  of  technical  risks  caused 
the  objective  to  be  dropped  in  favor  of  wire-based.  However,  several  proposals  of  fiber  optic  SMS  configurations 
were  received  and  evaluated  in  the  process  of  awarding  the  current  contracts.  As  components  mature  airborne  fiber 
optics  could  become  a  reality.  Figure  10  shows  the  impact  of  fiber  optics  on  the  specific  architecture  shown  in 
Figure  8.  The  SMS  configuration  will  include  five  identical  digital  fiber  optic  data  buses:  (a)  avionics  bus,  (b)  stores 
management  bus,  (c)  left-wing  store  stations  bus,  (d)  fuselage  store  station  bus,  and  (e)  right-wing  store  stations  bus. 
Each  bus  employs  a  six-terminal  reflective  star  coupler  and  single-fiber  cable  pigtails  (without  connectors). 

The  resolution  of  two  critical  issues  arising  from  prior  fiber  optics  development  of  airborne  applications  was 
completed  and  may  be  of  interest.  An  analog  decoder  technique  was  successfully  used  to  eliminate  the  signaling 
errors  typically  encountered  in  fiber  optic  data  bus  systems  which  employ  2-State  Manchester  Coding.  An  improved 
LED  driver  technique  was  developed  which  provides  increased  output  power  at  wide  bandwidth.  Both  techniques 
can  now  be  exploited  in  airborne  fiber  optic  system  design  effort. 


Software  Development  Tools 

A  major  objective  of  the  AAAS  effort  is  to  develop  systems  hardware  and  software  which  provides  rapid,  very  low 
cost,  minimum  modification,  and  capability  growth.  The  addition  of  new  weapons  to  older  aircraft  weapon  suites 
represents  this  need.  One  of  the  contractors  selected  for  the  ASMS  development  will  implement  a  concept  which 
simplifies  the  generation  of  store  control  procedures,  store  control  tables  and  specific  aircraft  application 
configurations.  The  system  generation  portion  of  this  new  tool  is  diagramed  in  Figure  11.  Development  of  this  tool 
provides  adaptability  to  reconfigure  software  among  various  processors  while  minimizing  any  software 
programming.  It  utilizes  table  driven  software  to  facilitate  control  sequence  changes  and  simplifies  addition  of  new 
stores  to  the  SMS. 
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Figure  10.  Contractor  B  SMS  architecture  with  fiber  optics  data  buses 


SMS  SUBSYSTEM  STANDARDS 

A  concept  which  may  be  utilized  for  the  evaluation  of  standardization  in  other  avionics  systems  has  been  developed 
under  AAAS  direction  effort.  A  set  of  criteria  were  developed  to  rank  subsystems  modules  or  components  (levels)  for 
the  application  to  standardization  by  any  of  several  approaches. 

Standardization  is  the  process  requiring  conception,  formulation,  dissemination,  enforcement,  and  revision  of 
standards.  Six  types  of  standardization  are  frequently  used  in  Government  and  industry.  These  standardization  types 
are  summarized  below. 

Horizontal 

Vertical 

Area 

Functional 

Logistical 

Cooperative 

Horizontal  standardization,  also  termed  general,  commodity,  or  intersystem  standardization,  refers  to 
standardization  of  items  (subsystems,  modules  or  components)  used  between  or  within  systems.  An  item  used  in 
more  than  one  system  (e.g.,  utilizing  an  AN/AYK-14  in  more  than  one  aircraft  series)  may  also  be  used  by  more 
than  one  military  service  and  often  satisfies  multiple  missions.  Example  is  AN/AYK-14. 

Vertical  standardization,  also  known  as  specific,  project,  product,  or  intrasystem  standardization,  refers  to 
standardization  of  a  project  or  product  from  design  to  operation.  Vertical  standardization  includes  an  item  used  in 
all  configurations  of  a  single  system.  Example  is  AN/AYQ-9  in  all  F-18  aircraft. 

Area  standardization  is  standardization  of  items  by  geographic  or  mission  area  rather  than  between  or  within 
systems.  When  there  is  more  than  one  supplier  or  application  of  a  given  item,  these  items  are  typically  similar  but 
not  identical.  Therefore,  to  meet  area  or  mission  needs,  items  are  standardized  within  a  mission  or  geographic  area, 
whereas  similar  but  not  identical  items  are  used  between  areas  or  missions.  Example  of  area  standardization  is  to  use 
functionally  similar  items  for  strike  and  surveillance  aircraft,  but  identically  standardized  items  in  a  specific  mission 
area  (e.g.,  strike  aircraft). 

Functional  standardization,  also  known  as  form,  fit  and  function  (F3)  standardization,  is  primarily  concerned  with 
the  standardization  of  electrical,  mechanical,  logistical,  and  environmental  interfaces.  Items  built  to  F3  standards 
may  differ  significantly  internally,  but  always  have  identical  size,  shape,  and  function.  Commercial  airlines  have 
employed  this  form  of  standardization  for  many  years  in  the  specification  of  avionics.  This  form  of  standardization  is 
also  used  to  establish  joint  service  standards  (MIL-STD-1760)  and  NATO  standards  (STANAG  3837 AA). 


i 
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Logistical  standardization  is  the  specification  of  every  aspect  of  an  item,  including  the  detailing  of  its  parts, 
processes,  and  configuration.  Examples  of  logistical  standardization  are  military-qualified  electronic  components 
managed  by  the  Defense  Electronics  Supply  Center.  Each  logistically  standardized  item  is  identical  in  every  respect 
to  other  standardized  items. 

Cooj -  rative  standardization  is  the  development  of  design  standards  (examples  include  threads,  fitting  sizes,  and 
materials)  by  all  users,  both  industry  and  DoD. 

Standardization  studies  conducted  over  the  past  few  years  have  recognized  that  not  all  items  make  good 
standardization  candidates,  for  technical,  operational,  or  economic  reasons.  Presently  there  are  no  universally 

acctptijd ,  (^udiititirthc  tiioasaits  1 1 T  i uTi.nig  tlxt  ZiTliscla  v  wi.wSS  "  A  a  1  jt 

However,  general  guidelines  for  making  such  evaluations  have  been  developed  in  recent  AAAS  studies.  Four  general 
selection  criteria  were  developed  and  applied  that  were  widely  accepted  by  the  R&D  community.  These  criteria  are 
briefly  as  follows: 

Technological  -  The  technology  must  be  mature. 

Architectural  -  The  subsystem  must  perform  identifiable,  discrete,  and  separable  functions. 

Applicability  -  The  system  specification  must  be  broadly  applicable  to  weapon  system  requirements. 

Economic  -  A  sufficient  market  must  exist  for  new  systems  within  the  period  under  consideration. 

It  is  realized  that  these  criteria  are  not  a  comprehensive  set  of  considerations  for  selecting  standardization 
candidates;  however,  a  review  of  SMS  subsystems  against  these  factors  encourages  a  disciplined  examination, 
providing  useful  insight  into  the  issues  that  must  be  reconciled. 

Table  3  categorizes  these  criteria  for  ranking  the  seven  AAAS  SMS  subsystems  for  potential  standardization.  Table  4 
shows  the  results  of  applying  the  criteria  and  rationale  together  with  each  subsystem  candidate’s  raw  score  and 
ranking. 


Table  3  STANDARDIZATION-RANKING  CRITERIA  FOR  SMS  SUBSYSTEMS 


Category 

Criteria 

beast  Attractive  (1) 

Moderately  Attractive  (2) 

Most  Attractive  (3) 

Technological 

Performance  requirements 
change  frequently;  state-of- 
the-art  pacing  equipmenta. 

Functionally  similar  equip¬ 
ments  exist  in  the  inventory. 
Improvements  (primarily  pack¬ 
aging,  reliability,  etc.)  are 
expected. 

Previous  standardisation 
precedent  exists. 
Equipment  currently 
exhibits  high  HTBF  using 
proven  technology  and 
mature  designs. 

Architectural 

High  degree  of  intercon¬ 
nectivity  with  other 
avlonica  subsystems;  moder¬ 
ate  or  higher  degree  of  soft¬ 
ware  implementation  within 
aubayatem. 

Low  degree  of  interconnec¬ 
tivity  with  other  subsystems; 
moderate  or  higher  degree  of 
software  implementation 
within  subsystem. 

Low  degree  of  intercon¬ 
nectivity  with  other 
subsystems;  very  low 
software  implementation. 

Appl lcability 

Uaed  only  in  aircraft  with 
almilar  performance  charac¬ 
ter  latica  or  that  operate  in 
identical  threat 
environmenta. 

Used  serosa  multiple-aircraft 
types  and  in  other  military 
services. 

Multiple  mission  and 
multiple  aircraft  or 
commercial  usage. 

Economic 

Few  auppliera  and  low  annual 
demand  rate  -  limited 
opportunity  for  competition. 

Some  suppliers  and  medium 
annual  demand  rate  -  some 
opportunity  for  competition. 

Many  suppliers  and  high 
annual  demand  rate  - 
unlimited  opportunity 
competition. 

..Aw 


Table  4 


STANDARDIZATION  SCORES  AND  RANKING  FOR  SMS  SUBSYSTEMS 


Standardization  Criteria  Application  and  Ranking 

SMS 

Subsystem 

Technological 

Architectural 

Applicability 

Economic 

Raw 

Score 

Rank 

Control  and 
Display 

Equip. 

2 

1 

1 

2 

6 

7  th 

Process 

Control 

Equip. 

3 

2 

2 

3 

10 

3rd 

Store 

Station 

Equip. 

2 

2 

1 

2 

7 

6th 

Aircraft 

Interface 

Equip. 

2 

1 

2 

2 

7 

5th 

Data 

Transfer 

Equip. 

3 

3 

3 

3 

12 

1st 

Software 

3 

3 

2 

3 

11 

2nd 

Briefing 
Entry  Device 

3 

2 

2 

3 

10 

4  th 

Note:  3  ■  Most  Attractive,  2  -  Moderately  Attractive,  1  *  Least  Attractive 


A  discussion  of  the  rationale  for  ranking  the  top  four  subsystems  follows. 


Data  Transfer  Equipment  (DTE) 

Data  Transfer  Equipment  is  considered  most  attractive  for  standardization  based  upon  all  criteria.  DTE  has 
standardization  precedents  (e.g.,  the  MIL-STD-I553  multiplex  data  bus),  highly  standardized  means  for 
interconnectivity  with  other  systems,  and  multiple  mission/aircraft  applications.  Many  companies  supply  DTE 
components,  thus  sustaining  an  unlimited  opportunity  for  competition. 

As  a  result  of  the  above  analysis,  DTE  was  given  the  highest  raw  score  of  all  SMS  subsystems  (12/12)  and  hence  is 
regarded  as  the  most  attractive  for  standardization.  All  standardization  approaches  except  functional  are 
recommended,  and  standardization  is  achievable  at  all  levels. 


Software  (SW) 

The  software  subsystem  is  considered  most  attractive  for  standardization  in  all  categories  except  applicability. 
Previous  standardization  precedent  exists  (e.g.,  standard  HOL  and  MIL-STD-I679)  and  SW  interfaces  can  be  strictly 
defined  through  interface  design  specifications.  Further,  there  are  several  potential  suppliers  of  the  SW  subsystem, 
thus  providing  an  unlimited  opportunity  for  competition. 

The  SW  subsystem  as  judged  moderately  attractive  based  on  the  applicability  criterion,  since  only  portions  of  the 
SMS  subsystem  (e.g.,  executive  programs)  may  be  used  across  multiple-aircraft  types  and  potentially  in  other 
military  services.  It  is  expected  that  selected  modules  of  SMS  subsystems  (e.g.,  application  programs)  will  be  needed 
to  accommodate  different  aircraft  configurations  and  store  suites. 

The  SW  subsystem  accumulated  a  raw  score  of  11/12  and  was  judged  the  second  most  attractive  of  the  SMS 
subsystems  candidates  for  standardization.  Standardization  to  the  module  level  is  considered  feasible. 


Process  Control  Equipment  (PCE) 

Process  Control  Equipment  is  rated  most  attractive  for  standardization  on  the  basis  of  technological  and  economic 
criteria  (see  Tables  3  and  4).  PCE  scores  well  in  these  areas  since  there  is  precedent  for  its  standardization 
(AN/AYK-I4,  AN/AWG-9,  etc.),  and  such  equipment  utilizes  proven  technology  and  mature  designs.  Further,  the 
many  potential  suppliers  of  PCE  offer  an  excellent  opportunity  for  competition. 

PCE  is  considered  moderately  attractive  for  standardization  based  upon  architectural  and  applicability  criteria.  The 
reasons  are  that  PCE  interfaces  with  other  subsystems  (although  this  interface  is  increasingly  being  simplified 
through  the  use  of  standard  digital  multiplexes  busses),  and  typically  differs  in  capability  and  mission  supported. 
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The  PCE  reflects  a  total  raw  score  of  10/12  (see  Table  4)  and  ranks  third  overall  as  an  AAAS  subsystem  candidate 
for  standardization.  PCE  is  considered  feasible  for  standardization  at  all  assembly  levels  and  to  all  standardization 

dppiuatl.cs.  it.jwevc/,  laflctiojial  sTaudarJlzatiuii  is  u  Jl  ffcOOirrineiided  siiitJ  the  1  iglsricii  appimnJh  is  act  ievaOic  anu 

has  been  demonstrated  to  the  component  level. 


Briefing  Entry  Device  (BED) 

The  Briefing  Entry  Device  was  judged  most  attractive  based  upon  the  technological  and  economic  criteria,  and 
moderately  attractive  for  the  architectural  and  applicability  criteria.  From  a  technological  viewpoint, 
standardization  precedent  exists  (e.g.,  Data  Transfer  System)  and  equipment  making  up  the  Briefing  Entry  Device 
incorporate  proven  technology  and  mature  designs. 

Further,  there  ar.  many  current  suppliers  of  such  subsystems,  thus  offering  an  unlimited  opportunity  for 
competition. 

The  moderately  attractive  ratings  in  the  architectural  and  applicability  areas  were  assigned,  respectively,  because 
the  device  (1)  has  a  degree  of  interconnectivity  with  other  subsystems,  and  (2)  may  not  be  adaptable  across  multiple 
aircraft  types  in  a  single  configuration. 

By  applying  the  above  criteria,  the  Briefing  Entry  Device  attained  a  raw  score  of  10/12,  suggesting  that  it  is  a 
favorable  candidate  for  standardization.  All  standardization  approaches  except  functional  are  recommended. 
Standardization  to  the  module  level  is  considered  feasible,  wnile  complete  component  standardization  may  be 
difficult  due  to  a  requirement  to  adapt  to  different  aircraft  types  and  missions. 


CONCLUSIONS 

The  series  of  concepts  discussed  above  were  selected  for  potential  application  or  interest  by  other  avionics 
developments.  Due  to  a  shortage  of  advanced  development  funds  the  application  of  these  and  other  concepts  may 
not  be  carried  further  by  the  AAAS  program. 


THIS  INFORMATION  IS  FURNISHED  UFON  THE  CONDITION 
THAT  IT  OR  KNOWLEDGE  OF  ITS  FOSSESSION  WILL  NOT 
•E  RELEASED  TO  ANOTHER  NATION  WITHOUT  SPECIFIC 
AUTHORITY  OF  THE  DEPARTMENT  OF  THE  NAVY  OF  THE 
UNITED  STATES,  THAT  IT  WILL  NOT  IE  USED  FOR 
OTHER  THAN  MILITARY  PURPOSES;  THAT  INDIVIDUAL 
OR  CORPORATE  RIGHTS  ORIGINATING  IN  THE  INFORMATION. 
WHETHER  PATENTED  OR  NOT.  WILL  SE  RESPECTED;  THAT 
THE  INFORMATION  WILL  IE  PROVIOEO  THE  SAME  OEGREE 
OF  SECURITY  AFFORDED  IT  SY  THE  DEPARTMENT  OF 
DEFENSE  OF  THE  UNITEO  STATES 
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DISCUSSION 


R.Davies,  Ca 

With  regard  to  MIL-STD-1 760  -  has  any  consideration  been  given  at  Naval  Weapons  Center  (or  elsewhere)  to 
extending  the  interface  standard  beyond  the  physical  connection  between  the  aircraft  and  the  store  (weapon 
missiles,  etc.),  for  example,  with  a  data  link  or  wire-guided  missile  or  a  back  link  from  an  E-O  weapon  etc? 

Author’s  Reply 

To  my  knowledge  no  one  is  looking  at  this  or  for  that  matter  pushing  it.  My  instinct  would  be  to  let  it  mature  a  bit 
before  standardization. 


M.Burford,  UK 

In  your  presentation,  you  have  identified  that  where  there  is  a  software  interface,  the  standardization  of  the  stores 
management  system  is  “unattractive”.  This  appears  to  be  in  direct  contrast,  in  respect  to  standardization,  to 
previous  speakers.  Could  you  please  outline  the  thoughts  which  have  led  to  this  conclusion? 

Author’s  Reply 

Somehow  we  did  not  communicate  well.  The  section  in  my  paper  on  SMS  subsystem  standardization  states  very 
clearly  that  the  software  as  an  SMS  subsystem  is  a  most  attractive  candidate.  I  believe  this  to  be  in  agreement  with 
most  other  speakers. 


K.F.Boecking,  Ge 

You  presented  two  different  architectures  for  a  SMS.  In  system  “A”  the  display/control  system  corresponds  to  the 
SMS  via  the  avionics-bus.  In  system  “B”,  the  SMS-Bus  has  its  own  D/C-system  at  the  SMS-Bus.  Could  you  explain 
the  reason  for  a  separate  D/C-system  in  the  “B”-SMS? 

Author’s  Reply 

The  separate  controls/displays  functional  block  on  SMS  system  “B”  is  for  the  safety  required  separate  discrete 
controls  which  cannot  be  integrated  into  multi-function  controls  through  the  avionics  bus.  Actually,  all  proposals 
received  were  identified  in  this  characteristic  including  SMS  “A”.  A  look  at  the  SMS  system  “A”  figure  in  the  paper 
will  confirm  this. 


L.Wildharer,  Ca 

As.d  i o>f  ji&urihg  ifaKidtaJtotton.  01  faiciptio  ■  to  cafitiintasd  tat  *yile*n  Cjj  U  ths  UK  AKtttL  bw 
429  for  interphasing  between  standard  commercial  avionics  systems  (digital)  and  aircraft  weapon  systems?  This 
refers  to  Table  3  Applicability  -  Most  attractive  (3). 

Author’s  Reply 

Yes,  under  study  with  regard  to  input-output  parameters  for  standardization. 


G.R. England,  US 

(1)  Future  for  SMS  implementations  where  real  time  data  is  required  will  likely  be  a  network  rather  than  a 
hierarchal  bus  system.  A  switched  network  would  be  applicable  to  any  type  of  real  time  requirement. 

(2)  Master  arm  type  data  is  generally  made  available  to  the  rest  of  the  avionics  by  means  of  a  discrete  to  the  Fire 
Control  Computer.  By  this  means,  the  data  can  be  put  on  the  bus  yet  retain  necessary  isolation  for  safety. 

Author’s  Reply 

(1)  Yes,  thank  you,  an  excellent  point. 

(2)  Again,  thank  you,  for  help  in  answering  the  question  from  Germany. 


LIAISONS  AVION-CHARGES  EXTERNES 


PAR 

C.  CONNAN 
M.  SALAUN 

AVIONS  MARCEL  DASSAULT  -  BREGUET  AVIATION 
78,  Quai  Carnot 
92214  SAINT-CLOUD 

1  -  RESUME 

L'dvolution  en  complexity  des  charges  externes  dites  simples  (bombes),  le  nombre  de  plus  en  plus 
important  des  paramdtres  demandds  par  les  charges  plus  complexes  (missiles  et  surtout  nacelles)  rend 
indispensable  la  numdrisation  d'un  maximum  de  matdriels. 

Ceci  conduit  &  standardiser  le  procddd  de  liaison  numdrique  (type  de  liaison  et  gestion).  Alors  les 
saulas  autres  informations  restant  4  inter  facer  sont  des  informations  de  sdcuritd  et  des  informations  &  large  bande 
passante,  elles  peuvent  dtre  commutdes  en  fonction  du  chargement  de  l'avion  &  condition  d'avoir  prdvu  un  systdme 
d'idantification  at  d'adressage  des  charges.  Par  sdcuritd  les  informations  autori3ant  le  tir  des  armes  ne  sont  pas 
entidrement  numdrisdes  et  sont  sdgrdgudes  dlectriquement  des  autras  signaux. 

Le  projat  da  stanag  3837  propose  dgalement  une  standardisation  das  intarfaces  dlectriques  des  charges 
extarnas  afin  de  rdpondre  aux  mdmes  besoins  que  ceux  de  notre  dtude.  Cepandant  il  impose  le  type  de  liaison 
numdrique  de  l'avion,  ce  qui  n'est  pas  ndcessaire  pour  l'intdropdrabilitd  ;  toutes  les  sdcuritds  sont  traitdes  par 
doublage  de  la  liaison  numdrique  sans  aucuna  liaison  spdciala. 

Dans  une  phase  intermddiaire  il  ast  possible  d'aboutir  progressivement  &  l'architecture  que  nous 
axposons  ici  dans  da3  avions  existants,  en  cours  de  ddvaloppament  ou  d  ddvaloppar  :  dans  l'ordre  nous  trouvons 
d'abord  liaison  numdrique,  puis  aiguillaga  des  informations  analogiques,  puis  numdrisation  das  ordres  da  tir  prdcis. 

2  -  INTRODUCTION 

Cette  publication  reprdsenta  la  point  da  vua  das  Avions  Marcal  Dassault  -  Brdguet  Aviation  vis  &  vis 
des  architectures  de  liaisons  avac  les  chargas  axtemas. 

Le  but  de  l'dtuda  prdsantda  ast  de  standardisar  au  maximum  les  intarfaces  dlectriques  antre  las  avions 
et  las  charges  extarnes  afin  de  minimisar  : 

-  les  dtudes  d'adaptation  pour  i'adaptation  de  chaque  type 

-  les  ddveloppemants  da  matdriels  spdcifiques  de  charge  externe  &  chaque  type  d'avion 

-  les  modifications  des  cflblagas  et  d'installation,  lors  de  I'adaptation  d'une  rtouvalle  charge  externe  d  un  avion.  Le 
but  n'est  pas  l'interopdrabilitd  des  avions,  sans  eucune  modification  de  logiclel  ou  das  adaptations  au  niveau  des 
points  d'emport,  mais  essentiellament  ne  pas  modifiar  le  matdriel  interne  d  l'avion,  et  agir  uniquement  au 
niveau  du  logiclel. 

3  -  EVOLUTION  DES  CHARGES  EXTERNES 

Une  classification  possibla  des  charges  externes  en  fonction  de  lours  dvolutions  propres  actuellas  est  la 

suivente  : 

-  les  bombes  dont  les  installations  mdcanlques  sont  standardisdes  (tout  au  moins  pour  les  systdmes  d'accrochage 
et  les  djections)  (cf  §  3.1). 

-  les  missiles  qui  sont  toujours  installds  sur  des  lanceurs  spdcifiques  (cf  §  3.2). 
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-  les  nacelles  soit  qui  possadent  des  adaptateurs  macaniques  int6gr6s,  soit  qui  se  montent  comme  des  bombes  (cf 
§  3.3). 

Cette  classification  ne  prend  pas  en  compte  les  interfaces  spacifiques  au  tir  mais  uniquement  les 
liaisons  "fonctionnelles". 

3.1  -  Bombes 

Les  bombes  ont  avolua  en  partant  de  systfcmes  extrSmement  simples  ne  n^cessitant  aucune  liaison  avec 
l'avion  vers  de3  systbmes  de  plus  en  plus  sophistiqu^s  n6ce3sitant  de  plus  en  plus  de  liaisons  avec  l'avion. 

Trfes  grossiferement  Involution  des  interfaces  avion-bombe  permettant  de  transmettre  des  informations 
fonctionnelles  est : 

-  aucune  liaison  entre  l'avion  et  l'arme 

-  les  informations  nScessaires  &  l'arme  sont  m^caniquement  (ou  parfois  aiectriquement)  affich^s  sur  l'arme  au  sol 
avant  le  depart  en  mission.  Ceci  n^cessite  d'introduire  les  mfimes  informations  dans  It.  systfeme  avion  par  un 
autre  moyen.  D'ou  des  risques  de  contradiction  et  d'erreur  non  nggligeables. 

-  les  informations  sont  en  nombre  trbs  r^duits  (2  cas  possibles  seulement)  et  sont  transmis  par  les  cables 
macaniques  commandant  les  Securitas  largables. 

-  afin  de  minimiser  les  consignes  aux  pilotes  et  augmenter  le3  performances  des  systfemes  les  informations  sent 
transmises  aiectriquement  de  l'avion  a  la  bombe.  Compte-tenu  des  technologies  disponibles,  une  liaison 
numdrique  est  choisie  (ce  qui  permet  agalement  d'avoir  une  prise  de  plus  faible  dimension).  Mais,  dans  l'espoir 
de  minimiser  le  coOt  de  l'arme  (qui  est  consommable),  la  liaison  est  la  plus  simple  possible  et  g6n6ralement 
spdcifique 

-  les  kits  de  propulsion  sont  envisages  sur  certains  types  de  bombes 

3.2  -  Missiles 

L'dvolution  des  interfaces  dans  le  cas  des  missiles  est  : 

-  liaison  uniquement  pour  le  tir  (amorgage  des  piles,  allumage  du  propulseur,  etc...) 

-  liaisons  analogiques  fonctionnelles  de  plus  en  plus  nombreuses 

-  liaisons  numdriques  +  liaisons  discr&tes  d'identification  +  liaisons  de  sacurita  +  liaisons  a  large  bande  passante 
(blankings  et  synchronisations  avec  les  contre-mesures  et  le  radar  en  particular,  liaisons  viddo).  La  liaison 
numdr  que  est  gdndralement  choisie  en  fonction  de  la  complexity  nacessaire  (nombre  d'informations  a 
transmettre,  rapidity  de  transmission  nacessaire,  prycision  de  la  dytection  des  informations) 

-  des  systimes  d'extraction  permettant  de  protager  les  prises  de  la  flamme  des  propulseurs  sont  de  plus  en  plus 
employ  as. 

3.3  -  Nacelles 

L'avolution  des  nacelles  est  tras  proche  de  celle  des  missiles  si  ce  n'est  qu'il  n'y  a  pas  de  liaison  pour  le 
tir.  Cependant  elles  peuvent  nacessiter  des  alimentations  en  anergle  aiectrique  relativement  importantes. 

4  -  DEFINITION  DU  BE5QIN 

4.1  -  Standardisation 

Le  nombre  d'informations  oiffarentes  a  transmettre  entre  les  avions  et  les  nombreuses  charges 
extemes  qu'ils  dolvent  emporter  (compte-tenu  de  lour  polyvalence  de  plus  en  plus  grande)  conduit : 

-  soit  a  multiplier  les  bottes  d'interfaces,  (blen  que  les  fonctions  raallsaes  par  ces  diffarentes  bottes  alent  de 
nombreux  points  communs),  les  torons  de  cftblages  et  les  commutations  de  ciblage  a  l’intarieur  de  l’avion.  C'est 
la  solution  qui  exlste  dans  les  avions  actuellement  en  service  ; 

•  soit  a  standardlser  les  liaisons  entre  l'avion  et  les  charges  exteries  ;  ce  qui  lmplique  : 

.  de  numariser  au  maximum  les  informations  et  les  transmettre  par  une  liaison  numarlque  standardisae. 

.  que  les  liaisons  non  numarisables  seront  aigulliaes  dans  l'avion  par  des  aqulpements  spaciallsas. 
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4.2  -  Liaison  numdrique 


L'avantaga  assantiel  da  la  liaison  numdrique  est  de  pouvoir  changer  les  informations  qui  sont 
transmises  sans  avoir  6  modifier  le  material  avion. 

La  liaison  numdrique  doit  Stre  utilisde  au  maximum  et  descendre  le  plus  en  aval  possible  dans  les 
charges  externes.  En  particulier,  tous  les  problbmes  de  sdquencement  et  da  tir  doivent  dtre  traitds  par  cette 
liaison.  Les  gros  avantagas  de  la  liaison  numdrique  conduisent  b  un  gain  de  volume  et  de  masse  et  un  gain  dans  la 
disponibilitd  globale  du  systbme.  Ceci  implique  en  particulier  que  le  gdrant  de  la  liaison  numdrique  soit  capable  de 
reconnattre  cheque  dquipement  relid  6  la  liaison.  Pour  ce  qui  concerne  les  charges  externes,  ces  dquipements  sont 


-  das  interfaces  dans  les  pylones 

-  des  interfaces  dans  les  adaptateurs  spdcifiques. 

-  les  charges  externes  alles  mSmes  qui  peuvent  comporter  plusieurs  dquipements. 

Tout  ceci  implique  la  standardisation  : 

-  des  adressages  des  charges  externes  sur  la  ligne  numdrique.  Au  niveau  de  chaque  point  d’emport,  1'avion  doit 
done  foumir  une  adresse.  La  loi  d'adressage  au  niveau  de  chaque  point  ast  dgalement  standardisde  avec  une 
capacitd  d'adressaga  suffisante. 

-  chaque  dquipement  doit  dtra  capable  de  s'identifier  ;  un  code  standard  d'identification  doit  done  dtre  dtabli.  Un 
moyan  annexe  est  ndcassaire  pour  les  charges  ne  possddant  pas  de  liaison  dlectrique  (affichaga  manuel  - 
ddtrompagas  mdcaniques). 

11  est  bien  dvident  que  s'il  doit  rester  des  liaisons  spdcifiques  au  niveau  des  emports,  il  en  rdsultera  des 
complications  considdrables  d""  probldmas  de  gastion  des  amports  qui  peuvent  conduire  jusqu'b  ndeessiter  des 
gdrants  locaux  de  liaisons  spd  jues  au  niveau  de  chacun  des  points  d'emport. 

Par  ailleurs,  las  liaisons  spdcifiques  impliquent  des  moyans  de  maintenance  spdcialisds  qui  ne  sont  pas  ndeessaires 
dans  le  cas  d'une  liaison  standardisda.  C'est  pourquoi  nous  essayons  d'dliminer  cas  liaisons  spdcifiques  dans  1'avion, 
1'adaptation  dventuella  dtant  dans  la  pylone  ou  1'adaptateur,  ca  qui  est  rdalisable  (voir  §  5.4.3)  et  permat  de 
rdpondre  au  basoin  d'interopdrabilitd. 

4.3  -  Liaisons  fonctionnallas  restantas 


Les  liaisons  fonctionnelles  restantas  sont  calles  qui  ne  sont  pas  numdrisables  sur  une  liaison  rtumdrique 

sdrie  : 

-  liaisons  b  large  bande  passante  de  type  : 

.  blanking  entre  dquipements  possddant  des  antennes  d'dmission  ou  de  rdeeption. 

.  synchronisation  (fdquipements  (synchro  radar  -  synchro  viddo  -  GPS  -  etc...) 

.  signaux  viddo  (fimagerie  (analogiques  ou  numdriques)  les  bandes  passantes  de  ces  sigr.  jx  viddo  coires- 
pondant  : 

a  aux  viddos  actuelles  (525  et  625  lignes) 

a  aux  viddos  en  court  de  ddveioppement,  en  particulier  pour  les  besoins  de  reconnaissance  (875  lignes). 

-  Liaisons  de  sdcuritd  de  type  : 

.  coupure  (^alimentation  efune  charge  exteme  ou  (Tune  partie  de  charge  externe.  Ce  type  de  liaison  existe 
aurtout  pour  des  nacelles  qui  ne  sont  pas  des  matdriels  consommables  et  qu'il  est  done  parfois  n  dee  ast  ire  de 
pouvoir  protdger  par  une  action  martuelle, 

.  automations  de  tir.  La  liaison  numdrique  permet  d'obtenir  des  instants  de  tir  prdcis  avec  un  minimum  de 
clblage  et  de  matdriel  dans  1’avion  mais  elle  ne  garantit  pat  une  probabilitd  de  tir  intempestif  ou  de  non  tir 
suffisamment  faible  pour  dtre  utilisde  teule.  C'est  pourquoi  il  reste  indispensable  de  n'alimenter  let  circuits 
de  tir  que  pendant  des  temps  courts  (sdcuritd  armament  levde  et  poutaoir  de  tir  enfoned  en  particulier). 


Bien  entandu,  compte  tenu  de  la  progression  rapide  des  technologies,  ces  liaisons  de  sEcuritEs  pourront  Etre 
patit  b  petit  partiellament  ou  totalement  supprimEes  et  remplacEes  par  des  redondances  au  niveau  des 
interfacas  at  des  gestionnaires  de  la  liaison  numErique.  L'Etat  actuel  des  tachnologies  ne  permet  cependant  pas 
de  les  supprimer  immEdiatemant  (bien  que  les  liaisons  numEriques  aient  des  fiabilitE  et  disponibilitE  de 
fonctionnament  globalemant  meillaures  que  celles  des  liaisons  analogiques) : 

.  les  probabilitEs  recherchEss  ne  sont  pas  atteintes  ou  sont  difficiles  b  dEmontrer 

.  les  redondancas  impliquent  Egalement  des  redondances  des  c9blage3  numEriques  qui  sont  trbs  pEnalisantes  en 
volume  parce  que  ces  liaisons  doivent  Stre  protEgEes. 

.  las  coOts  et  volumes  dans  les  technologies  actuelles  sont  trop  impoi  ..ants. 

4.4  -  Alimentations 


Les  alimentations  doivent  Stre  distributes  vers  chacun  des  points  d'emport.  Les  Evolutions  des  circuits 
d'alimantation  pour  les  avions  future  ne  sont  actuellement  pas  parfaitement  Etablies  ;  l'hypothbse  faite  est  done  de 
foumir  : 


-  du  200V  400  Hz 

-  du  28  V  continu 


b  chacun  des  points  d'emport  oil  une  charge  est  installEe  (une  nacelle  ou  un  missile  ou  un  lance  missile,  etc...). 

Les  technologies  actualles  conduisent  b  diminuer  les  consommations  des  Equipements.  Cependant  de 
gros  consommateure  apparaissent  de  plus  en  plus  nombreux,  en  particular  des  Emetteure  radio  Electriques  (de 
contra-mesure  par  exemple);  il  est  done  necessaire  de  foumir  les  meilleures  puissancas  possibles. 

5  -  ARCHITECTURE  PROPOSEE 


Pour  rEpondre  aux  diffErents  besoins  axposEs  au  chapitre  prEcEdent,  une  architecture  de  systfeme  de 
gestion  des  points  d'emport  pout  Etre  proposEe.  La  synoptique  de  principa  ast  Etabli  en  annaxe. 


F.lle  est  bfltie  autour  d'un  systbme  de  gestion  numErique. 


5.1  -  Liaison  numErique 
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La  distribution  de  la  liaison  numErique  vars  les  points  d'emport  se  fait  en  Etoile  : 

•  ceci  permet  de  dEcoupler  Electriquement  le  bus  avion  de*  but  allant  vers  les  points  d'emport  et  chaque  point 
d'emport  Cun  per  rapport  k  1'autre.  En  particulier  il  n'y  a  pas  de  possibllitE  de  perturbations  mutuelles  au 
moment  du  tir  (Tune  arme  ou  aprbs  son  tir. 

•  la  coupure  de  la  liaison  vert  Cun  des  points  d'emport  ne  conduit  pes  b  la  perte  des  liaisons  vers  tout  les  autres 
points  d'emport. 
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Cette  fonction  peut  Stre  realisee  de  plusieurs  man i fere 3  suivant  le  nombre  d'abonnfes  a  la  ligne 
numferiqua  : 

-  si  la  nombre  d'abonnfes  au  bus  avion  (fequipements  internes  fe  l'avion  +  fequipements  aux  points  d'emport)  est 
infferieur  au  nombre  maximum  d'abonnfes  possibles  par  bus  :  c'est  un  simple  rfepfeteur  de  bus  (simple  remise  en 
forme  des  signaux  eiectriques). 

-  si  la  nombre  d'abonnfes  au  bus  avion  est  supferieur  au  nombre  d'abonnfes  par  bus  :  c'est  un  coupleur  de  sous  bus 
(avec  adressage  complfementaire  de  sous  bus), 

-  si  le  nombre  d'abonnfes  installs  aux  points  d'emport  devient  trfes  grand  c'est  un  ensemble  de  coupleurs  de  sous 
bus. 

Ce  principe  permet  d'avoir,  pour  une  installation  avion  figfee,  la  possibility  de  faire  fevoluer  le  systfeme 
vers  un  plus  grand  nombre  d'abonnfes  par  simple  remplacement  de  l'fequipement  faisant  la  repartition  de  bus  vers 
les  points  d'emport. 

5.1.2  -  Repartition  de  bus  au  niveau  de  chaque  paint  d'emport 

Afin  de  minimiser  les  volumes  et  les  coQts  dans  les  fequipements  de  charges  extemes,  la  repartition  de 
bus  au  niveau  des  points  d'emport  se  fait  : 

-  par  repartiteur  passif  (transformateur  +  resistance)  tant  que  le  nombre  d'abonnes  au  bus  fe  un  point  d'emport 
dortne  n'est  pas  superieur  au  nombie  maximum  possible  pour  un  bus, 

-  si  toutefois  ce  nombre  etait  depasse  pour  un  point  d'emport  donne  (ce  qui  est  trfes  peu  probable)  il  devient 
nfecessaire  d'installer  des  coupleurs  de  sous  bus  au  niveau  des  points  d'emport. 

5.1.3  -  Numferisation  de  la  fonction  tir 

Afin  de  profiter  au  maximum  des  possibilitfes  de  la  liaison  numerique  les  paramfetres  permettant 
d'obtenir  un  instant  de  tir  precis  sont  transmis  sur  la  liaison  numerique  : 
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Afin  de  minimiser  les  risques  de  tir  intempestif,  les  circuits  de  tir  ne  sont  alimentes  que  lorsque  toutes 
le3  3ecurites  sont  lavees  (train  -  security  generala  armament  -  poussoir  de  tir  -  palettes  aerodynamiques).  Cette 
security  est  realisee  de  fagon  classique  par  materiel  dans  l'avion. 

Les  progrfes  tachnologiquas  davraient  permettre  ulteriaurement  da  suprimar  cas  liaisons  de  security  ; 
par  axemple  : 

-  redondance  mu.'tiple  du  traitement  logicial  das  differents  inverseurs  de  security  dans  l'avion  avac  votaur  en 
sortie, 

-  redondance  multipla  das  outils  de  liaison  numerique  (il  n'ast  pas  nfecessaire  de  redonder  le  cable  lui-mfeme), 

-  yventuellemant  redondanca  de  ['interface  de  tir. 

Cecl  ne  sera  posslbla  qua  lorsque  ces  fonctions  pourront  6tre  realisees  dans  des  volumes  reisonnables 
et  fe  des  coOts  faibles  ;  ce  qui  n'est  pas  le  cas  fe  ltiaure  actuella. 
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L'intarface  de  tir,  situda  dans  les  pylones,  trancforme  les  signaux  ragus  sur  le  bus  (prdcis  sur  l'dchelle 
des  temps)  an  signaux  capables  : 

-  de  rdaliser  la  sdquencemant  du  tir  : 

.  tir  successif  de  plusiours  armes  emportdes  sous  le  mdme  pylone, 

.  sequence  pour  une  seule  arme  :  activations  de  piles,  suppression  de  verrou,  mise  6  feu  de  propulseur,  etc... 

-  de  foumir  une  dnergie  suffisante  aux  diffdrents  systdmes  pyrotechniques 

5.2  -  Aiquillaqe  des  liaisons  fonctionnelles 

Pour  une  mission  donnde  (ou  parfois  pour  une  phase  de  mission  donnde  seulement)  un  signal  analogique  issu  de 
I'avion  n'est  utilisd  que  sur  un  point  d'emport  &  la  fois.  II  y  a  done  un  aiguillage  programmable  de  ces  signaux 
rdalisds  dans  un  dquipement  installs  dans  I'avion  : 

-  signaux  de  sdcuritd  (hors  largage  et  tir) 

ces  signaux  sont  en  fait  issus  d'inverseurs  situds  sur  des  postes  de  commande  en  cabine  pilote.  A  chaque 
inverseur  correspond  un  fil  allant  vers  un  point  d'emport  donnd  j  e'est  le  poste  de  commande  qui  est  rdalisd  en 
fonction  des  points  d'emport  et  non  en  fonction  des  types  d'emport. 

-  signaux  viddo 

plusieurs  gdndrations  successives  de  systdmes  peuvent  Stre  envisagdes  : 

.  la  viddo  n'est  utilisde  que  pour  visualisation  et  enregistrement, 

x  une  seule  viddo  est  utilisde  simultandment  dans  I'avion:  une  commutation  simple  (1  parmi  N)  suffit  avec 
sdparation  des  circuits  de  sortie  : 


VIDEO  1 

COMMUTATION 

COMMANDEE 

PAR 

LOGIC  IEL 

_ 1 

\  UTIL ISATEUR  1  (EX.-VISU  AVANT) 

VIDEO  2 

1/ 

N  UTILISATEUR  2  (EX-.VISU  ARRIERE) 

VIDEO  si. 

_ 1 

1/ 

N  UTILISATEUR  3  (EX:  MAGNETOSCOPE) 

? 

i  deux  viddos  sont  utilisdes  simultandment  dans  I'avion  :  la  commutation  est  plus  complexe  (2  parmi  N).  Ce 
cas  sa  prdsente,  par  example,  si  Ton  veut  visualiser,  soit  das  viddos  diffdrentes  aux  diffdrents  membres  de 
I'dquipago,  soit  des  viddos  diffdrantas  au  pilote  en  monoplace. 

.  la  viddo  eat  dgalement  utilisda  pour  rdaliser  des  traitements  d'imaga  dans  I'avion  :  una  commutation  n  parmi 
N  est  alora  ndeessaire. 

-  signaux  de  blanking 

le  qdrant  de  ce  typa  da  signaux  est  gdndralament  l'dquipement  gdrant  des  contremasures.  A  un  instant  donnd, 
las  signaux  6  aigulllar  vars  la  gdrant  das  contre-masures  sont  issus  : 

.  des  diffdrentes  nacelles  de  contremesures, 

.  de  l'arma  qui  est  sur  le  point  d'Stre  tlrda 

-  signaux  de  synchronisation  radar 

un  aiguillaga  simple  depuis  le  radar  vars  le  missila  sur  la  point  d'fttre  tird  suffit  dans  ce  cas. 

Les  autres  signaux  sont  tous  numdrisablas.  Si  des  signaux  de  type  phonie,  par  axemple,  doivent  dtre 
foumis  &  des  nacalles  da  transmission,  una  commutation  simple  est  suffisanta. 


5.3  -  Circuits  de  tir  et  de  larqaqa 


Las  circuits  de  tir  at  de  largage  peuvant  dtre  classes  an  : 

-  circuits  de  tir  opdrationnal 

-  circuits  de  ddtressa  dvolude  (largaga  combat  -  largaga  sdlectif) 

-  circuits  de  ddtrassa  gdndrale. 

Les  deux  premiers  types  de  circuits  ndcessitent  des  sdquences  complexes  et  variables  en  fonction  des 
conditions  de  tir.  Une  gastion  par  calculateur  est  ndcessaire  ainsi  qua  la  transmission  par  liaison  numdrique.  Le 
troisifeme  type  doit  dtre  disponibla  mdme  aprds  perte  totale  de  1'alimentation  alternative  de  l'avion  et  du  systdme 
d'arma. 

Afin  de  rdpondre  a  ces  deux  critdres  et  de  conserver  une  certaine  redondance  des  circuits  utilisant  les 
calculateurs  de  gestion  numdrique  ^architecture  suivante  des  circuits  oe  tir  est  proposde  : 


La  matdriel  ast  utilisd  pour  le  tir  opdrationnel  secours  et  pour  les  ddtresses  intelligentes  ;  ceci  afin  de 


minimisar  le  matdrial  ndcessaira  at  de  profiter  du  maximum  des  possibilitds  des  logiciels.  Le  largage  ddtresse  ne 
fait  pas  intervenir  de  logiciel  at  reste  compldtement  inddpendant  du  reste  du  systdme. 

L'dvolution  de  la  technologie  devrait  permattre  dans  le  futur  de  redonder  cartaines  parties  de  circuits 
(avec  comparaisons  par  votaurs  par  exempla)  dans  des  volumes  trds  faibles  et  autorisar  la  suppression  de  certains 
cdblagas  da  sdcuritd. 

5.4  -  Rdalisation  du  systfeme 
5.4.1  -  Technoloqla 
5.4.1. 1-  Protection  das  liaisons 


L'dvolution  des  avions  d'armes  conduit  4  das  protections  das  liaisons  plus  poussdes  : 

-  sensibility  des  liaisons  numdriques 

-  structures  des  avions  en  matdriaux  non  mdtalliques 

-  envlronnement  radiodlectrique  des  avions  d'armes  da  plus  en  plus  sdvdre. 
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Ceci  impose  : 

-  des  liaisons  numdriques  transitant  sur  paires  torsaddes  blinddes  spdciales  avec  continuity  de  blindage  parfaite  y 
compris  au  passage  des  prises, 

-  liaisons  d  large  bande  passante  par  cables  coaxiaux  avec  passages  coaxiaux  au  niveau  des  prises  et  si  possible 
blindage  triaxial  conformdment  au  STANAG  3350, 

-  dventuellement  remplacement  des  liaisons  numdriques  dlectriques  par  des  liaisons  numdriques  &  fibres  optiques  ; 
les  transcodages  dlectrique  optique  se  font  alors  au  niveau  des  prises  terminales. 

Ces  conditions  conduisent  encore  plus  &  souhaiter  une  minimisation  du  nombre  de  liaisons  filaires  vers 
les  points  d'emport  qui  sont  des  points  gdographiques  particuliferement  perturbds. 

5.4.1.2-  Prises 

Les  prises  d  installer  aux  points  d'emport  (d  la  fois  sur  l'avion  -  sur  les  pylones  et  adaptateurs  -  sur  les 
charges  externes  elles  mdmes)  doivent  Stre  standardisdes  et  rdpondre  aux  critdres  suivants  : 

-  sdgrdgation  des  lignes  d'autorisation  de  tir  :  sdparation  mdtallique  (sdparation  des  champs  dlectrique  et 
magndtique)  dans  la  mdme  prise  ou  prise  sdparde, 

-  passages  spdciaux  pour  les  paires  torsaddes  blinddes  des  lignes  numdriques, 

-  passages  coaxiaux,  et  si  possible  triaxiaux,  pour  les  liaisons  d  large  bande  passante. 

Ces  prises  peuvent  dtre  ddveloppdes  d  partir  de  prises  type  DBAS  existantes  et  comportant  en 
particular  des  passages  pour  paires  numdriques. 

5.4.1.3-  Matdriels  dlectroniques  4  installer  au  niveau  des  points  d'emport 

Les  conditions  d'environnement  au  niveau  des  points  d'emport  sont  trds  sdvferes  (en  particulier  pour  la 
tempdrature  et  les  vibrations).  Par  ailleurs,  les  volumes  disponibles  pour  installer  de  tels  dquipements  dans  des 
pylones  ou  adaptateurs  sont  trds  faibles  ;  il  est  done  indispensable  que  les  composants  utilisds  soient  largement 
intdgrds  et  tiennent  aux  hautes  tempdratures  et  niveaux  de  vibration  dlevds  ;  l'dtude  thermique  de  ces 
dquipements  doit  dtre  particulidrement  soignde. 

5.4.2  -  Gestion  de  l'ensembla 

5.4.2.1-  Orqane  qdrant 

Le  ou  les  organe(s)  gdrant(s)  est  (ou  sont)  un  (ou  plusieurs)  calculateuHs)  quelconque(s)  du  systdme 
d'arme  soit  spdcialement  prdvu(s)  pour  la  gestion  de  l'armement  solt  dgalement  utilisd(s)  d  d'autras  tdches.  Afin 
d'avoir  le  minimum  de  redondance  ndeessaire  pour  les  probldmes  de  tir,  il  faut  qu'au  moins  une  partie  de  la  gestion 
soit  doublde  (soit  bi  procasseur  -  soit  deux  calculteurs). 

5.4.2. 2-  Adre8saqe 

L'avion  foumit  une  adresse  d  chaque  point  d'amport  (deux  valours  de  rdfdrence  :  isold  et  masse 
structure)  foumis  par  cinq  fils.  Au  niveau  de  chaqua  point  d'emport,  l'adresse  dvolue  en  suivant  une  loi  prdcise  trds 
simplement  rdalisable  matdriellement  : 


A  :  adresse  foumia  par  I'avion 


.  U  prend  l'adresse  A  foumie  par  I'avion 
.  p  prend  l'edresse  (A  +  1) 

.  Cj  prend  l'adresse  (A  +  2) 

.  C2  prend  l'adresse  (A  +■  3) 

.  etc... 


(A  +  1) :  signifie  adresse  suivante  dans  la  suite. 

La  repartition  est  feite  par  ia  fonction  R  situde  dans  1'edaptateur  lorsqu'il  y  a  plusieurs  charges  sous  le 
mdme  point  d'emport 


S.4.2.3-  Identification  des  charges 


Cheque  charge  et  cheque  dquipement  sur  le  bus  numdrique  eu  niveeu  des  points  d'emport  foumissent 
leur  code  d'identification  sous  le  forme  d'un  ou  plusieurs  mots  de  32  bits  composds  comme  suit  : 


ftr  octet 


bit  structure  s  Rdserve 

sur  bus 

coda  sur  pyione 
coda  sur  adaptateur 


2  it  me  octet  iinw.  octet  4iime  octet 


nom  de  l'dquipement 


modification  : 
iogiciel 
matdriel 


ia  nom  de  l'dquipamant  est  composd  : 

-  d'une  catdgorie  (3  bits)  s  missile,  bomba,  ECM,  etc... 

-  d'un  numdro  d'ordra. 

5.4.3  -  Liaisons  numdriques  particulidres 

Pour  certalnes  armes,  il  sera  ndcassaire  de  ddvalopper  une  liaison  particulars  axtrdmament  slmplifida 
;  par  example  s'il  est  ndeessaire  de  transmettre  des  informations  6  das  roquettes,  alias  peuvent  6tre  transmises 
par  induction,  il  n'y  a  alors  pas  de  prisa  dlectrique  sur  les  roquettes. 


Per  allleurs,  un  volume  (trds  petit)  est  rdservd  dans  les  pylones  pour  les  liaisons  particulidres.  Par 
example,  si  le  bus  numdrlque  da  I'avion  est  de  type  GINA,  un  transcodage  GINA  1553  B  peut  dtre  installd  dans  ce 
volume  j  cecl  permat  d'emporter  des  charges  utlilsant  le  standard  1553  B  sur  les  avions  utilisant  le  standard  GINA 
semi  aucune  modification  matdrlella  de  I'avion,  seules  des  modifications  de  Iogiciel  sont  ndcessalres. 


6  -  COMPARISON  AVEC  LE  PROJET  DE  STANAG  3837 


STANAG  3837 


PROPOSITION 


-  depend  de  ['architecture  interne  SNA 

.  BUS  REDONOANT 
.  BUS  1333 

-  pas  de  segregation  de  l'autorisation  de  tir  par  rapport 
aux  alimentations 

-  sdcurite  uniquement  assume  par  doublage  de  la  ligne 
numerique 

-  pas  de  protection  particulibre  des  cSblages  contre 
les  perturbations  radioeiectriques 

-  liaison  par  fibre  optique  en  plus  du  bus  eiectrique 

-  le  Ir.rgage  detresse  nbcessite  la  ligne  numerique 

-  pas  de  rfegle  de  progression  d'adressage 

-  pas  de  rfegle  d'identification  des  charges 

-  architecture  avec  points  d'emports  en  derivation 


-  ne  depend  par  de  1'architecture  interne  SNA 

.  bus  non  obligatoirement  redondant 
.  TYPE  DE  BUS  :  non  specifie 

-  autorisation  de  tir  eiectromagnetiquement  separee 
des  alimentations 

-  securite  assuree  par  discrets 

-  protection  des  liaisons  contre  les  perturbations 
radioeiectriques 

-  bus  optique  b  la  place  du  bus  eiectrique  (transcodage 
dans  la  prise) 

-  le  largage  detresse  est  independant  de  la  ligne 
numerique 

-  rfegle  de  progression  d'adressage 

-  rfegle  d'identification  des  charges 

-  preference  (mais  pas  d'obligation)  pour  une 
structure  en  etoile  pour  separer  les  probifemes  lies  b 
chaque  point  d'emport. 


7  -  EVOLUT1V1TE  DE  LA  SOLUTION  PROPOSEE 


La  solution  presentee  peut  6tre  appliquee  proqressivement  sur  les  avions  en  suivant  1'ordre  suivant  b 
condition  que  chaque  element  de  la  chatne  soit  realise  de  fagon  modulaire,  chaque  module  pouvant  btre  remplacb 
par  un  module  plus  evolue  en  fonction  de  l'avancement  des  etudes,  realisations  et  technologies. 


7.1  -  Ligna  numerique 

La  premifere  chose  b  standardiser  est  la  ligne  numerique,  sans  redondance  dans  un  premier  temps. 


Caci  implique  en  particulier  dbs  la  depart  d'avoir  etahli  les  rbglas  d'adrassage  et  d'idantification. 


L'augmentation  du  nombre  de  charges  extamas  abonnees  au  bus  augmentera  progressivement.  Cela 
conduira  b  faira  evoluar  le  repartitaur  da  bus  :  au  depart  c'ast  un  rbpbteur  da  bus,  puis  un  couplaur  de  sous  bus 
simple,  puis  eventuallamant  un  coupleur  de  sous  bus  multiple. 


L'intarfagage  de  chaque  charge  axtame  ou  equipament  doit  sa  faire  par  un  module  tachnologiqua, 
lntarchangeabla  (carta  ou  composants,  ate...)  de  fagon  b  pouvoir  changer  la  type  da  liaison  numerique  trbs 
rapidemant. 


7.2  -  Aiquillaqas  analoqiques 


C'est  chronologiquement  la  deuxlbme  problbma  qu'il  convient  de  standardiser.  Les  matrices  d'algull- 
lages  peuvent,  dans  un  premier  temps,  btre  simples  (1  parmi  N)  puis  pius  complexes  (n  parmi  N).  L'un  das 
problbmes  lie  b  1'aiguillage,  est  la  quantite  de  cbbles  arrivant  b  un  point  unique  ;  il  peut  done  btre  Intbressant  de 
hlbrarchiser  cet  aigulllage  afin  da  mieux  rbpartir  les  problbmes  de  connectique  b  1'intbrieur  de  1'avion.  Pour 
chaque  signal  vers  chaque  point  d'emport,  il  faut  done  un  module  technologique  sbparb  qui  pourra  evoluer  dans  la 
temps  en  fonction  de  la  complexitb  demandbe  et  des  possibllltbs  technologiquas.  Cartaines  liaisons  nbcessitant 
aujourd'hul  des  aiguillages  permettent  d'bvoluer  vers  des  bus  numbriques  spbcifiques  (par  axampla  bus  vidbo  sur 
liaison  b  fibre  optique). 


Ls 


7.3  -  Tir 


[.'utilisation  da  la  liaison  numErique  pour  la  tir  le  plus  en  aval  possible  dans  le  circuit,  c'est-b-dire  au 
nivaau  des  pylones,  nEcassite  la  dEveloppemant  de  composants  trfes  intEgrEs  fonctionnant  dans  un  environnement 
trbs  sEvfere.  Ceci  peut  Etre  fait  dans  un  troisiEme  temps  sans  avoir  &  modifier  ni  ies  charges  extemes,  ni  les 
cEblages  de  l'avion. 

Cet  Equipament  devra  Egalement  Stre  rEalisE  de  maniEre  modulaire  en  particulier  de  fagon  &  pouvoir 
rEduire,  par  la  suite,  la  nombre  da  sEcuritEs  par  discret. 

7.4  -  SEcuritEs 

Dans  un  premier  temps  les  sEcuritEs  sont  assurEes  par  des  liaisons  spEcifiques.  Les  Evolutions 
technologiques  peuvent  permettre  des  redondances  multiples  des  circuits  d'interface  de  la  liaison  numErique  avec 
vote(s).  Les  sEcuritEs  par  discrets  pourront  alors  Etre  supprimEes  par  remplacement  des  interfaces  dans  les 
Equipaments  concernEs  (pylones  -  adaptateurs  -  charges  extemes). 

8  -  MAINTENANCE 

La  standardisation  des  interfaces  des  charges  axtemes  rend  possible  l'utilisation  des  matEriels  de 
maintenance  standardisEs  qui  sont  les  mfimes  quelle  que  soit  la  charge  externe  installEe  sous  l'avion.  Par  ailleurs, 
les  mfimes  matEriels  peuvent  servir  &  tester  1'installation  avion  et  les  charges  externes  elles-mSmes.  11  est  alors 
facilement  envisageable  de  rEaliser  la  maintenance  de  l'avion  sans  matEriel  extErieur  (maintenance  intEgrEe).  La 
maintenance  intEgrEe  permet  Egalement  de  faire  la  maintenance  des  charges  extemes  installEes  sous  avion  sans 
utiliser  de  matEriel  supplEmentaire,  des  logiciels  sont  intEgrEs  dans  les  calculateurs  de  l'avion. 
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DISCUSSION 

R.Cope,  UK 

In  the  diagram  in  your  Annex,  a  connection  is  shown  between  the  SMS  and  the  computer  and  during  the 
presentation  you  spoke  of  automatic  weapon  identification.  Can  you  tell  us  whether,  and  if  so  to  what  extent,  this 
information  is  made  available  to  the  operational  flight  programmes,  for  use  in  configuration  warning  and  flight 
control  calculations,  for  example? 

Rlponse  d’Auteur 

L’information  d’identification  est  principalement  utilisee  pour  l’initialisation  au  sol  mais  est  accessible  a  tout 
moment  pendant  le  vo'.  Les  controles  du  centrage  et  de  sy  me  trie  de  masse  utilisent  une  combinaison  de 
l’information  d’identification  et  de  reformation  de  presence  de  charge. 


SUMMARY  OF  SESSION  II 
AVIONICS  AND  SYSTEM  STATE-OF-THE-ART 


by 

W.F.Ball 

Session  Chairman 


The  papers  of  Session  II  primarily  dealt  with  the  subject  of  avionic  systems  integration,  fault-tolerant  design 
approaches,  fault  detection  and  bus  structured  systems  architectures. 

The  first  paper  of  this  session  was  entitled  “Towards  the  Functional  Partitioning  of  Highly-Integrated,  Fault- 
Tolerant  Avionics  Signal  Processors”,  by  Mr  J.A.Rey  of  Northrop  Corporation.  In  his  paper,  Mr  Rey  viewed  the  Fighter/ 
Attack  aircraft  of  the  future  as  a  highly  integrated  weapon  system,  integrating  (vice  stand  alone)  functions/subsystems 
such  as  penetration,  target  acquisition,  weapon  delivery,  threat  detection  and  suppression  and  flight/engine  control. 
Especially  with  the  advent  of  VHSIC/VLSIC  processors  in  the  near  future,  it  will  be  possible  to  move  toward  fault 
tolerant  computing  architectures  that  both  assure  safety  of  flight  and  provide  a  significant  advance  in  operational 
capability.  Mr  Rey  discussed  issues  relating  to  the  architecture  of  such  near  future  systems  wherein  sensor  blending/data 
fusion/high  speed  operation  are  to  be  successfully  achieved.  He  also  provided  some  consideration  of  the  reliability  of 
such  systems. 

The  second  paper  by  Mr  R.C.Drummond  and  J.L.Looper  of  McDonnell  Aircraft  was  entitled,  “Advanced  F/A-l  8A 
Avionics”.  The  paper  was  presented  by  Mr  Looper.  This  paper  described  in  some  detail  the  current  F/A-l  8  and  indicated 
some  of  the  possible  enhancements  to  be  made  on  the  aircraft  in  the  future.  The  growth  capacity  of  the  F/A-l  8  was 
discussed,  reviewing  the  spare  computer  memory,  excess  electrical  power,  abundant  cooling  air  and  some  remaining 
physical  space.  This  will  allow  ease  of  expansion  in  capability  in  the  future.  A  reconnaissance  version  of  the  aircraft  is 
under  development.  Because  of  the  flexibility  and  safety  of  the  digital  flight  control  system,  the  current  design  will  serve 
as  an  excellent  test  bed  for  advanced  flight  control  studies.  Capitalizing  on  the  built-in  growth  potential  of  the  F/A-l  8, 
advanced  aircraft  programs  aimed  at  exploitation  of  these  capabilities  are  underway. 

Fapfcf  iturtibei  ttnefc,  'DEI  STAN  uo-I  tt .  A  Family  of  COii.patiulfc  Digital  Interface  5iainl&fds'',l)y  D.R.Bia*. lentil 
and  A.A.Callaway  of  RAE  Famborough,  was  read  by  Mr  D. Oldfield,  also  of  Farnborough.  This  paper  provided  a  detailed 
look  at  the  UK  MOD  Defence  Standard  (DEF  STAN  00-18)  which  is  the  definitive  UK  Standard  for  digital  interfaces  in 
aircraft.  Four  standards,  under  the  DEF  STAN  00-18,  have  been  published  so  far  by  the  joint  MOD(PE)/Industry  Data 
Transmission  Standards  Committee  (DTSC).  The  four  standards  published  so  far  are:  Multiplex  Data  Bus  Standard  (MIL 
STD  1553B  has  been  redrafted  into  the  DEF  STAN  00-18  format,  remaining  technically  identical  and  preserving  compat¬ 
ibility),  Single-Source,  Single/Multiple  sink  Interface  Standard  (a  more  simple  standard  than  1553B),  Discrete  Signal 
Interface  Standard  (Time-critical  Signaling,  non-time-critical  signaling  and  low  power  switching),  and  Fibre  Optic  Trans¬ 
mission  Standard  (although  many  standards  and  definitions  are  given,  further  work  is  needed).  Additional  work  by  DTSC 
will  take  into  account  the  accommodation  of  advances  in  technology  and  the  development  of  new  requirements.  This 
work  has  laid  a  good  basis  for  UK  aircraft  work  and  for  full  participation  in  international  standardization  activities. 

The  next  paper,  by  Mr  W.H.Hall  of  British  Aerospace,  was  concerned  with  the  subject  “Techniques  for  Interbus 
Communication  in  a  Multibus  Avionic  System”.  Mr  Hall  described  the  work  that  British  Aerospace  (Brough)  has  concen¬ 
trated  on  relating  to  interbus  communication.  Whereas  Ids  company  has  worked  with  MIL  STD  1553  for  some  four 
years,  their  work  on  an  Advanced  Systems  Demonstrator  Rig  for  MOD  has  pointed  out  the  lack  of  definition  of  interfacing 
between  buses  (a  typical  problem  encountered  in  developing  multibus  architectures).  Interbus  message  types  to  be  dealt 
with  include  Bus  Controller  (BC)  to  Remote  Terminal  (RT)  with  BC  &  RT  on  different  buses  and  RT  to  RT  where  the 
two  RTs  were  on  separate  buses.  Both  synchronous  and  asynchronous  message  transfers  were  considered.  The  paper 
suggests  that  this  work  can  be  used  to  extend  the  1 553  message  transfer  protocol  to  work  in  a  multibus  environment. 

Paper  five  was  entitled  “A  Video  Bus  for  Weapons  Systems  Integration”  by  Dr  L.Currier  and  E. Miles,  General 
Dynamics,  Fort  Worth.  Dr  Currier  noted  that  with  the  advent  of  MIL-STD-1 760  (Standard  Stores  Interface),  while 
system  transparency  is  preserved  with  minimal  restrictions  imposed  on  the  airframe  manufacturer,  it  would  still  be  very 
difficult  to  meet  the  standard,  physically  and  electrically,  with  discrete  wiring.  Especially  this  is  the  case  with  the  wing 
sizes  of  modem  fighter  sized  aircraft.  The  standard  calls  for  two,  bi-directional  video  lines  at  each  store  station. 

Dr  Currier  described  a  video  bus  approach  which  is  under  development.  This  approach  will  permit  a  common  “video 
IdglrtfBj”  with  fsrge  LarnJwrtHh  *c  aHo*  gfumnete.-  ftemoWy  tnw'efm-allm  ■mss* 

the  bus. 
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The  sixth  paper  of  this  session  was  written  by  J.Ostgaard  and  A.Zann  of  Wright  Patterson  AFB  (AFAL).  The  subject 
was:  “Network  Communications  for  a  Distributed  Avionics  System”.  This  paper  dealt  with  the  issue  of  evaluating 
inttjA  evHtonu.dvi’iw..  leihimfttes  k  AS lEm  It  prv.inn.iug  eaiidnhik  appfefeticS  kt  Ik^Al’s  eBt  aJwn  ivTCu  &Tiv/iuwo 
architectures.  The  basic  philosophy  of  the  architectures  to  be  experienced  in  that  timeframe  was  discussed.  To  deal  with 
these  architectures,  the  paper  suggests  that  MIL-STD-1 553B  is  too  limited  and  that  a  new  data  bus  needs  to  be  developed 

lliai  Iii^oTpvndTeS  1 353b  a. id  that  cal  aduicaa  ilic  Tulu.c  icquliciuciila.  Mi  visigaaid  ^ncaciitcd  a  detailed  -c view  at  Ida 

e  'aluation  criteria  and  methodology.  After  looking  at  the  evaluation  results,  the  authors  suggest  that  an  enhanced  1 553B 
approach  might  be  the  best  choice,  lowest  risk  approach  for  the  future.  The  study  described  in  the  paper  is  aimed  at 
influencing  future  standards  for  bussing. 

The  seventh  paper,  “Avionics  Fault  Tree  Analyzer”,  by  M.E.Harris,  McDonnell  Aircraft,  gave  a  description  of  a 
Microprocessor  controlled,  ground-based  test  set  for  the  F/A-l  8  aircraft.  This  equipment,  which  is  man-portable, 
communicates  with,  exercises,  interrogates  and  diagnoses  the  Avionics  Subsystem  in  the  aircraft.  In  some  cases,  the  AFTA 
isolates  wiring  as  well  as  electronic  faults.  The  AFTA  interfaces  with  the  aircraft  via  a  single  connector  and  has  an 

ne  f  plasma  dfcplap  fb !  *  ponttl  ll  *pp**“S  Ihit  uidfaiwy  k  irtiWputtlm  I*#  *  t?T A 

function  within  the  aircraft  as  future  memory  and  computer/avionics  capability  will  permit. 

The  eighth  paper  by  M.E.L.Courtois  of  Avions  Marcel  Dassault-Breguet  Aviaion,  .was  entitled,  “Maintenance  Premier 
Echelon  Intdgrde  dans  les  Systemes  d’Armes”.  This  paper  dealt  with  First  level  integrated  maintenance  for  armament 
systems,  as  indicated  in  the  title.  Mr  Courtois  described  an  integrated  maintenance  approach  that  produced  many 
advantages.  It  allows  for  growth  in  the  digital  hardware.  It  permits  investigation  of  failures  without  flight  simulation  and 
does  so  without  external  hardware,  except  where  required  by  individual  weapons  systems.  The  method  allows  investiga¬ 
tion  of  failures  in  flight  (some  of  which  are  not  always  evident  on  the  ground).  Likewise,  it  permits  instantaneous  search 
and  validate  functional  channels  related  to  the  armament  system.  This  test  capability  is  built-in  to  systems  such  as  the 
Mirage  2000  utilizing  the  “Digibus”  mechanization  and  is  done  so  with  25K  words  of  memory . 

The  final  paper  of  Session  II  was  a  very  interesting  paper  presented  by  Dr  S.J.Kubina  of  Concordia  University, 
Montreal  a,T2  P.bfraTTia,  bkL,  JtlaVd.  ll.c  tvpk  Was  wlksTn.d  Willi  “CoT.lyUkT  Graphics  T.. hid.,  u.5  f_r  Aircralt  EMU 
Analysis  and  Design”.  While  the  subject  was  computer  graphics,  the  presentation  itself  was  veil  illustrated  with  dual 
ll  mm  Jttki  If.*  Jr  ns  graphically  ittj._-.tfar  Ul  Kdmm  JmcriTax'  tt  cjfljHii-'iViJ lyifcat 

for  the  prediction  of  the  potential  interaction  between  avionics  systems  with  particular  attention  paid  in  the  paper  to 
antenna-to-antenna  coupling.  The  strength  of  Dr  Kubina’s  approach  lies  in  the  effective  graphics  visibility  that  is 
aikid.u  t.  th.  Wvavvus/avivhics  sy’siv...  designer,  tins  vialttUy  ol  th.  emit.  tMi  B.WhwJlIvii  manix  ptaduies  insight 
into  the  design/physical/electrical  characteristics  of  the  aircraft  heretofore  not  available.  Because  of  the  visual  aiding 
presented  to  the  designer,  it  is  clear  that  this  is  indeed,  a  very  powerful  tool. 
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TOWARDS  THE  FUNCTIONAL  PARTITIONING  OF  HIGHLY  INTEGRATED, 
FAULT  TOLERANT  AVIONICS  SIGNAL  PROCESSORS 


J.A.  Rey 

Northrop,  Corporation,  Aircraft  Division 
Hawthorne,  CA.  90250 
USA 

ABSTRACT 

X 

Avionics  systems  for  new  interdiction  fighter  aircraft  require  a  high  degree  of 
integration,  translated  into  automation  for  crew  operations,  of  such  formerly  diverse 
subsystems  of  penetration,  target  acquisition,  weapon  delivery,  threat  detection  and 
suppression  and  flight/propulsion  control.  Also  coupled  into  this  is  the  infusion  of 
VHSIC/VSLIC.  All  this  implies  the  need  for  a  fault  tolerant  system  to  ensure  flight 
safety  and  high  operational  ability.  This  paper  discusses  some  of  the  partitioning 
(configuration) issues  involved  in  the  integration  process.  Specifically,  this  paper 
addresses  itself  to  the  issues  involved  with  the  functional  partitioning  into  ^generic* 
high  speed  signal  processors  and  how  this  partitioning  will  cross  some  of  the 
traditional  interlaces  between  such  things  as  flight  control  systems  and  avionics 
systems  and  subsystems  within  the  avionic  suite.  Of  special  interest  is  the 
partitioning  for  sensor  blending/data  fusion/hi-speed  data  buses  as  pertains  to  terrain 
following/terrain  avoidance  function  and  how  the  critical  path  computations  can 
be  made  fault  tolerant  and/or  allow  for  graceful  degradation  so  that  flight/mission 
safety  is  assured.  Also  discussed  are  the  methods  for  computing  reliability  values 
based  on  these  new  configurations  so  that  fault  tolerant  evaluations  methods,  such 
as  the  Markow  process,  may  more  realistically  be  computed.  4/ 


CONSIDERATIONS  AND  IMPLICATIONS  FOR  ADVANCED  TACTICAL  FIGHTER  AVIONICS 


Requires  a  very  high  degree  of  integration  due  to  automation  of  crew  functions  (reduction  of  crew 
work-load) 

Each  subset  was  built  (manufactured)  by  a  supplier  who  had  all  knowledge  of  how  to  make  his  subset 
work.  He  was  not  concerned  how  other  subsets  within  the  aircraft  worked, rather,  he  maximized  his 

own  subset  both  technically  and  from  a  business  point  of  view - For  example  a  radar  manufacturer 

did  not  process  any  data  from  a  FUR  or  Digital  Map  unless  he  felt  he  needed  it  then  he  put  It  In 
his  own  sensor/processor  and  this  Is  what  he  delivered  to  the  Integrator.  The  integrator  only 
worried  how  to  get  It  Into  the  AC  and  how  to  train  the  pilot  (until  now  basically  an  airplane  driver) 
how  to  use  It.  With  the  advent  of  cynerglsm  each  subset  is  no  longer  standalone.  The  prime 
Integrator  Is  responsible  for  "putting  It  all  together"  and  cannot  rely  on  subset  manufactures  to 
solve  his  (the  prime's)  weapon  system  problems.  Hence  we  have  such  things  as  "sensor  blending". 

The  cynerglsm  of  a  multiple  set  of  sensors  to  provide  solution  oriented  (artificial  intellegence)  data 
to  the  crew  member  dictates  the  blending  of  diverse  information  at  the  earliest  possible  point 
within  the  system. 


CONSIDERATIONS  &  IMPLICATIONS 


SCOPE . THE  PARTITIONING  S  DISTRIBUTION  OF  SIGNAL  PROCESSING  TASKS  FOR 

AN  INTEGRATED  FIGHTER/ATTACK  AIRCRAFT  AVIONIC  SYSTEM. 

WHY . —TRADITIONALLY,  SIGNAL  PROCESSING  WAS  AN  INTEGRAL  PART  OF  A 

FUNCTIONAL  SUBSETS  SUCH  AS  A  RADAR,  FLIR,  INERTIAL  SET. 


NOW 


•SIGNAL  PROCESSING' 
DATA  PROCESSING- 
SUBSETS. 


■MANY  TIMES  CANNOT  BE  DISTINGUISHED  FROM 
-IS  NO  LONGER  UNIQUELY  INTEGRAL  TO 


PRESENT  METHOD  OF  INTEGRATION 


PRIME  ACQUIRES  COMPLETE  OR  NEARLY  COMPLETE  FUNCTIONAL  EQUIPMENT  SETS  THEN 
INTEGRATES  EACH  FUNCTION, 


MAJOR  CONSIDERATION  IS  THAT  THE  SYSTEM  PERFORMANCE  IS  MAINLY  DETERMINED  BY 
THE  INDIVIDUAL  PERFORMANCE  OF  EQUIPMENT  SET  WITH  THE  SYSTEM  INTEGRATION 
PRIMARILY  CONFINED  TO  CONTROL  AND  DISPLAY. 


PRIME 

INTEGRATOR 


LEVEL 

SUPPLIER 


LEVEL  PRIME  INTEGRATES  FUNCTIONAL  EQUIPMENTS 

SUPPLIERS 


t 

\ 

f 


Sr 


NEW  METHOD  OF  INTEGRATION 


THE  PRIME  WILL  ACQUIRE  VARIOUS  SENSOR  ELEMENTS  FROM  SUPPLIERS:  PROCESSING  ELEMENTS 
FROM  SUPPLIERS  AND  THEN  THROUGH  THE  PROCESS  OF  DEVELOPING  SOFTWARE  INTEGRATE  AN 
AVIONIC  SYSTEM. 

THIS  METHOD  WILL  REQUIRE  A  NEW  METHOD  OF  DEALING  WITH  DIFFERENT  TYPES  OF  SUPPLIERS, 
NAMELY  SUPPLIERS  OF  SOFTWARE  AND  ALGOR I TH I MS.  MOSTLY  THE  FUNCTIONALITY  OF  THE 
EQUIPMENT  ELEMENTS  WILL  BE  SEPARATED  FROM  THE  SYSTEM  FUNCTIONS.  I.E.  EQUIPMENT 
FUNCTIONS  WILL  BE  TO  SENSE  SIGNALS  AND  SYSTEM  FUNCTIONS  WILL  BE  TO  PERFORM  TERRAIN 
FOLLOWING. 


INCLUDES  IMBEDDED  SOFTWARE 

PRIME  BRINGS  TOGETHER  STANDARDIZED 
EQUIPMENT  ELEMENTS  -  CAUSES  SOFTWARE 


i  i  A  a  ittMiaiMiatiiK  ii  liiaiiBfriiafflMBi 


PROBLEM  POSED  TO  PRIME  SYSTEM  INTEGRATOR 


New  avionic  systems  will  not  be  Implemented  with  the  traditional  functional  subsets.  Most  likely 
subsets  will  be  Identified  according  to  the  following: 


Sensor  (Offensive) 
Sensor  (Defensive) 


Antenna  and  RF  Sections 


Processing  elements: 

Signal  Processing 

Data  and  Control  Processing 

Data  Transfer 

Storage 

Control/Dlsplay 


Is  the  distribution  or  the  assignment  of  the  System  Tasks  to  be  done  by: 

#  As  in  the  past  by  individual  processor  with  the  limits  being  throughput  and  memory  size? 

#  As  In  the  past  by  the  physical  entity  itself? 

No  to  both  of  the  above. 

#  -  First  some  Issues  need  to  be  Identified. 

-  What  constitutes  a  processor 

-  What  constitutes  connectivity. 

-  What  Is  embedded  vs  core 


There  are  others  but  these  will  do  for  now. 


PROBLEMS  POSED  TO  PRIME  SYSTEM  INTEGRATOR 


-  WHAT  IS  PARTITIONING 

-  WHAT  IS  FAULT  TOLERANCE 

-  HOW  IS  IT  DONE 


BY  WHO  IS  IT  DONE 
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WHAT  IS  A  PROCESSOR 


#  Is  It  a  multi  CPU  device. 

#  Is  it  a  complete  entity;  self  contained  with  its  own  memory  and  power 
supply  -  VHSIC. 

#  Is  it  to  be  generic. 

#  How  is  it  to  be  packaged . - 

-  One  per  box? 

-  Distributed  power  supply  (power  multiplex) 

-  How  is  it  qualified  to  present  MIL-E-5400? 

(is  MIL-E-5400  still  valid) 

WHAT  FUNCTIONS  WILL  THESE  PROCESSORS 
PERFORM 


•  SIGNAL  PROCESSING  FOR  SPECIFIC  SENSOR  TYPES 

FLIR 

RADAR  (X.  BAND:  MILLIMETER  WAVE.) 

DIGITAL  (MAP  DATA) 

C02  LASER 

•  HIGH  SPEED  MIXING  OF  SENSOR/MAP  DATA 

•  HIGH  SPEED  DETECTION  &  RECOGNITION  OF  THREAT  DATA  AND  CORRELATION  TO  MAP  OF  EITHER 
BRIEFED  ON  UN-BRIEFED  THREATS. 


WHAT  IS  A  PROCESSOR 


MOTHER  BOARD  WITH  ATR  BOX 

MANY  PROCESSOR  WITH  MANY  MOTHER  BOARDS 


WHEN  PARTITIONING  TASKS,  WHAT  IS  THE  CONSIDERED  TO  BE  THE  BASIC  BUILDING  BLOCK? 

WHAT  IS  FAULT  TOLERANCE 


#  REDUNDANT  If  so  to  what  level  triple  -  quad  -  etc. 

#  Not  hardware  but  software  redundant 

-  functionally  equivalent  but  different 

-  performance  levels  -  alternate  paths 

#  Drivers  -  come  from  mission  requirements  analysis 

Sorted  out  by: 

-  Vehicle  Saftey 

-  Mission  Critical 


Mission  Desirable 


WHAT  FUNCTIONS  WILL  THESE  PROCESSORS 
PERFORM 

#  SIGNAL  PROCESSING  FOR  SPECIFIC  SENSOR  TYPES 

FLIR 

RADAR  (X.  BAND:  MILLIMETER  WAVE.) 

DIGITAL  (MAP  DATA) 

C02  LAZER 

#  HIGH  SPEED  MIXING  OF  SENSOR/MAP  DATA 

#  HIGH  SPEED  DETECTION  &  RECOGNITION  OF  THREAT  DATA  AND  CORRELATION  TO  MAP  OF  EITHER 
BRIEFED  ON  UN-BRIEFED  THREATS. 


HOW  DO  THESE  FUNCTIONS  RELATE  TO  MISSION 


THE  "PRIME"  IS  RESPONSIBLE  FOR  PERFORMANCE  OF  THE  MISSION  FUNCTIONS.  IN  RELATING 
EQUIPMENT  OPERATION  TO  MISSION  FUNCTION,  THE  PRIME  WILL  DETERMINE  WHAT  ALGORITHMS 
ARE  TO  BE  IMPLEMENTED,  BY  WHO  AND  WHERE  THEY  WILL  BE  HOSTED.  THIS  IS  THE 
PARTITIONING  PROCESS.  THE  PRIME  WILL  USE  AS  HIS  DRIVING  ELEMENTS  SUCH  THINGS  AS: 

•  OVERALL  RELIABILITY  OF  THE  ELEMENTS  WHICH  PERFORM 
THE  FUNCTIONS. 

•  FLIGHT  CRITICAL,  MISSION  CRITICAL,  ETC. 

•  ALTERNATIVE  PROCESSES - I.E.  MORE  THAN  ONE  WAY 

TO  LOCATE  A  TARGET  USING  ALTERNATE  SENSORS  AND 
PROCESSING  PATHS. 


HOW  DO  THESE  FUNCTIONS  RELATE  TO  MISSION 


#  THIS  IS  THE  CRUX  OF  WHY  THE  PRIME  BECOMES  INTERESTED. 

LET  US  RELATE  TO  A  MISSION  PHASE 
LOW  LEVEL  PENETRATION 

FUNCTIONS: 

TERRAIN  FOLLOWING/TERRAIN  AVOIDANCE 
AUTOMATIC  FLIGHT  PATH  GENERATION 
AUTOMATIC  THREAT  DETECTION/AVOIDANCE/SUPPRESSION 
AUTOMATIC  TARGET  RECOGNITION 
DISPLAY  GENERATION 

ALL  THIS  REQUIRES  HIGH-SPEED  PROCESSORS  AND  IN  SOME  MEASURE  FAULT  TOLERANCE 

WHAT  IS  FAULT  TOLERANCE 


IF  THE  SYSTEM - SIGNAL  PROCESSOR - IS  TO  BE  FAULT  TOLERANT  IT  IS  NECESSARY  TO 

DEFINE  WHAT  IT  IS  FAULT  TOLERANT  TO: 

•  FIRST.  AS  ALREADY  MENTIONED,  THE  MISSION  FUNCTION  NEEDS  TO  BE 
CATEGORIZED  AS  TO  CRITICALITY. 

THEN  THE  RELIABILITY  OF  THE  ELEMENT  IS  EXAMINED  AND  IF  THAT  RELIABILITY  IS 

NOT  ADA9UATE  TO  MEET  THE  SYSTEM  AVAILABILITY - SOME  KIND  OF  FAULT  TOLERANCE 

IS  THEN  REQUIRED. 

•  WHAT  ALSO  NEEDS  TO  BE  ADDRESSED  IS  SOFTWARE  RELIABILITY.  THIS  IS  THE 
LATENCY  PROBLEM  ATTRIBUTED  TO  UNFOUND  PROBLEMS  IN  THE  SOFTWARE.  THEREFORE 
"COVERAGE*  OF  SOFTWARE  FAULTS  IS  REQUIRED  FOR  VEHICLE  AND  MISSION  CRITICAL 
FUNCIIONS. 


WHAT  IS  FAULT  TOLERANCE 


#  DRIVERS  -  IS  PARTITIONED  FUNCTION  INVOLVED  IN: 

VEHICLE  SAFTEY 
MISSION  CRITICAL 
MISSION  DESIRABLE 

#  ESTIMATES  OF  RELIABILITY  -  IC  LEVEL 

MOTHER  BOARD  LEVEL 
BOX  LEVEL 


•  HOW  TO  BE  TOLERANT 


REDUNDANCY 


FUNCTIONAL  ALLERNATIVE 


HARDWARE  ALONE  MOSTLY  SOFTWARE 

SOFTWARE  ALONE  ASSIGNED  TO  ALTERNATE 

(HOT-COLD  SPARES) 
PROCESSORS  WITH  DEGRADED 
PERFORMANCE 

(DYNAMIC  RECONFIGURATION) 

HOW  IS  IT  DONE 


•  DYNAMIC  RECONFIGURATION 

-  HAVE  A  MULTIPLE  SET  OF  PROCESSORS  WHICH  CAN  BE  DYNAMICALLY  RECONFIGURED 
(BY  A  SYSTEM  EXECUTIVE)  TO  ACCOMODATE  FAILURES  (IMPROPER  PERFORMANCE) 

#  THIS  INDICATES  THAT  EACH  PROCESSOR  IS  A  CLONE  OF  THE  OTHER  AND  ONLY  SOFTWARE 
ASSIGNED  AT  ANY  GIVEN  TIME  IS  DIFFERENT  -  CHARACTERISTICS  OF  WHICH  ARE: 


GENERIC  CPU 
DYNAMIC  MEMORY 
HIGH  SPEED  BUS 

MULTIPLEXED  POWER  BUS 


(INSTRUCTION  SET  &  WORD  LENGTH) 

(LOADABLE  FROM  MASS  STORAGE) 

(FOR  INTERPROCESSOR  -  AND  BULK  STORAGE  -  DATA 
IRANSFER) 

(TO  AVOID  SINGLE  POINTS  OR  FAILURE  CHAINS) 


...  -  - 


i 


BY  WHO  WILL  THIS  BE  DONE 


#  MOSTLY  BY  THE  PRIME  - 

PRIME  IS  RESPONSIBLE  FOR  MISSION  PERFORMANCE 

ASSISTED  BY: 

•  SOFTWARE  (ALGORITHM  DEVELOPERS)  HOUSES 

•  EQUIPMENT  ALEMENT  SUPPLIERS 

SUMMARY 

#  NEW  BURDEN  PLACED  ON  PRIMES 

#  NEED  TO  DEVELOP  NEW  WAYS  TO  WORK  WITH  SECOND  LEVEL  SUPPLIERS. 

#  NEED  TO  UNDERSTAND  HOW  TO  DETERMINE  "ELEMENT  LEVEL"  RELIABILITY  FOR  PURPOSES. 

-  MARKOV  MODELING  (SYSTEM  PERFORMANCE  LEVEL) 

-  DEGREE  (COVERAGE)  AND  METHODS  OF  FAULT  TOLERANCE 

-  FUNCTIONAL  PARTIONING 
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DISCUSSION 


L.Crovella,  It 

Do  you  think  that  your  approach  on  processors  partitioning  is  compatible  and  will  merge  in  the  future  into  the 
avionic  system  architecture,  as  described  by  Mr  G.R. England  in  the  first  paper  of  this  symposium? 

Author’s  Reply 

Yes,  if  the  signal  processor  is  a  “common-module”  such  as  shown  by  Mr  England.  The  merging  into  the  system 
architecture  would  be  performed  during  the  design  trade-off  analysis  for  the  core  architecture/topology. 

N.J.B. Young,  UK 

In  your  presentation  you  talked  about  achieving  fault  tolerance  by  being  able  to  down-load  a  program  to  another 
processor  (from  a  mass  storage  medium)  when  the  first  processor  was  found  to  be  faulty.  There  are  of  course  many 
other  methods  for  achieving  fault  tolerance.  Is  the  method  you  mentioned  your  preferred  technique  or  is  it  just  an 
example  of  methods  under  consideration? 


one  example  of  many  which  would  be  available  for  implementation, 
avionic  set  core  architecture/topology. 


Author’s  Reply 

No  this  is  not  a  preferred  technique  -  it  is  only 
The  method  selected  would  become  part  of  the 
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ADVANCED  F/A-18  AVIONICS 


R.  C.  DRUMMOND  AND  J.  L.  LOOPER 
MCDONNELL  AIRCRAFT  COMPANY 
MCDONNELL  DOUGLAS  CORPORATION 
P.O.  BOX  516 

ST.  LOUIS,  MISSOURI  63166 


SUMMARY 


i!. 


net'  Is  a  singl 
^Waited  Statey 


^•The  F/A-18  Horne, 
attack  roles  for  the^ 

■  Spain-^>  It  has  a  very  capable  multimission  weapon  system, 
fighter  and  attack  missions. 
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le-seat,  twin -engine  aircraft  designed  to  fulfill  fighter  and  light 
Navy  and  Marine  Corps,  and  is  being  purchased ^by-Canada,  Australia  and 
integrated  so  a  single  pilot  can  perform  both 


The  challenge  of  multimission  capability  is  to  provide  the  necessary  weapon  system  elements  for 
effective  air-to-air  and  air-to-surface  weapons  delivery  without  requiring  a  major  flight  line  change 
each  time  the  aircraft  is  reconfigured  with  armament.  The  answers  for  the  multimission  Hornet  are 
digital  technology  and  extensive  system  integration.  High  reliability,  large  scale  integrated  circuits 
and  microprocessors  are  employed  throughout  the  digital  avionics  suite.  Integration  among  avionic 
subsystems  is  accomplished  over  the  MIL-STD-1553A  dual  digital  multiplex  bus  under  control  of  two  mission 
computers.  As  illustrated  in  Figure  T,>the  Hornet  has  significant  growth  potential  in  addition  to  its 
present  capabilities.  Growth  capacity  includes  spare  computer  memory,  electrical  power,  cooling  air  and 
physical  space. > 
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FIGURE  1 


'!—  The  production  F,  \-18  configuration  is  being  improved  with  the  addition  of  current  developments  such 
as  the  Advanced  Medium  Range  Air  to  Air  Missile  (AMRAAM),  Airborne  Self  Protect  Jammer  tASPJ)'  and  the 
Joint  Tactical  Information  Distribution  System  (JTIDS).  A  reconnaissance  engineering  program  is  under 
way,  which  will  modify  the  nose  of  a  test  airplane  to  add  cameras  and  an  IR  line  scanner  to  the  existing 
high  resolution  radar  and  FLIR.  An  all-environment  attack  variant  is  being  studied . vrtiich  will  include  a 
higher  resolution  radar,  low  altitude  penetration  enhancement,  and  automatic  target  recognition.  The 
F/A-18  avionics  are  modern,  integrated,  and  flexible,  making  extensive  use  of  the  power  of  digital 
computer  technology.  Significant  growth  potential  is  built  in.  Programs  to  exploit  these  capabilities 
are  under  way. 

PRESENT  AVIONICS  CAPABILITY 

The  avionic  challenge  was  to  design  a  weapon  system  compatible  with  the  relatively  small  airframe 
and  not  require  a  major  flight  line  reconfiguration  each  time  it  was  converted  between  air-to-air  and 
air-to-surface  roles.  The  answer  for  the  Hornet  is  to  use  the  advancements  in  digital  avionics  tech¬ 
nology,  more  multiplexing  of  intersystem  data,  and  more  efficient  integration  to  eliminate  redundant 
equipment.  For  example,  the  F/A-18  has: 

o  Programmable  controls  and  displays  integrated  for  one  man  operation. 

o  A  long  range,  all-altitude,  all-aspect,  programmable  multimode  radar  with  excellent  look-down 
performance. 

o  Single  step  selection  for  long  range,  short  range  and  close-in  combat  firing  with  the  Sparrow, 
Sidewinder,  and  internal  20mm  cannon. 

o  Accurate  day  and  night  air-to-surface  delivery  of  conventional  and  guided  weapons  against  land  or 
sea  targets. 

o  Modularized  mission  software  structure  with  MIL  Standard  1553  dual  multiplex  bus. 


o  A  high  authority,  quad-digital,  control-by-wire  primary  flight  control  system. 
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o  Internal  electronic  warfare  equipment  for  threat  warning  and  defensive  countermeasures, 
o  A  self-contained  inertial  navigation  system. 

o  Designed-in  system  reliability,  maintainability,  and  survivability. 

o  Automatic  in-flight  maintenance  data  recording  for  avionics,  engine  and  airframe. 

The  avionics  suite  is  configured  in  seven  functional  groups,  Figure  2.  Most  intersystem  data  are 
transferred  over  the  1  megahertz  dual  digital  avionics  multiplex  bus,  which  is  controlled  by  the  mission 
computers.  Three  other  multiplex  buses  provide  specialized  dedicated  information  flow  between  the  stores 
management  processor  and  the  fuselage/wing  station  armament  decoders,  between  the  communication  system 
controller  and  the  up-front  control,  and  between  the  flight  control  computers  for  redundancy  management. 

Eighteen  of  the  subsystems  in  Figure  2  have  primary  processors  which  communicate  directly  on  the 
avionics  multiplex  bus.  There  are  20  other  microprocessors  which  are  integrated  either  through  the 
primary  processor  equipments  or  via  separate  discrete  signals. 


Computations  and  System  Architecture  -  Partitioning  of  the  F/A-18  mission  computations  and  decisions 
within  the  avionic  system  is  done  on  the  basic  premise  that  is  either  sensor/equipment-oriented,  or 
mission-oriented.  Sensor/equipment  oriented  computations  are  primarily  independent  computations,  such  as 
inertial  platform  control,  radar  signal  processing,  display  symbol  generation,  and  air  data  calculations. 
Mission  oriented  computations  include  tasks  such  as  air-to-air  and  air-to-surface  steering  and  weapon 
firing  computations,  integrated  cockpit  display  management,  and  selection  of  the  best  available 
parameters  from  various  candidate  sensors. 

Cockpit  Controls  and  Displays  -  The  requirements  for  small  size  and  good  pi  Lot  visibility  resulted 
in  an  instrument  panel  and  console  area  402  smaller  than  that  in  the  A-7  attack  aircraft  or  the  F-4 
fighter.  To  implement  the  multiraission  needs  and  to  achieve  one-man  operability  of  the  sensors  and 
weapons,  MCA1R  employed  computer-aided  control  and  display  techniques  developed  through  extensive  human 
engineering  analysis,  man-in-the-loop  simulation  and  flight  testing.  key  elements  are  computer 
controlled  real  time  programmable  cathode  ray  tube  (CRT)  displays  which  present  simultaneous  target, 
weapons,  sensor,  and  own  ship  flight  information;  computer  placement  of  cockpit  controls  when  and  where 
they  are  needed;  and  automatic  initialization  of  the  displays,  sensors  and  weapons  for  the  selected 
mission  mode. 


MCAIR  test  pilots  and  an  Air  Crew  Systems  Advisory  Panel  made  up  of  experienced  USN/USMC  pilots 
tested  the  designs  and  control/display  formats  throughout  the  development  program,  offering  suggestions 
and  reviewing  alternate  approacnes  to  evolve  the  current  design. 

The  resulting  crew  station,  Figure  3,  features  a  head-up  display  and  three  other  multipurpose 
cathode  ray  displays  driven  by  both  mission  computers,  an  integrated  up-front  control  panel  and  numerous 
time  critical/high  "g"  functicns  on  the  flight  control  stick  and  throttles. 

The  three  head-down  multifunction  displays,  which  each  have  20  programmable  switches  integrated 
around  their  display  periphery,  aud  t^e  p’-ogr!>m"’eVie  up-front  control,  collectively  replace  the  more  than 
a  dozen  separate  avionic  control  panels  of  previous  aircraft.  The  HUD  is  the  primary  flight  instrument 
for  both  navigation  and  combat,  eliminating  the  large  4  inch  ADI  ball.  The  right  hand  multifunction 
display  is  the  primary  control/display  for  radar  attacks.  The  left  hand  display  is  the  primary 
*  AH.t  il  fcUt  I  wf  i  4'  Ik  AAAjVfr.  ,  SfH#  cuullo  ,  lSjTiijty  Unlit—*  i 

functions.  The  Horizontal  Indicator  (HI)  presents  CRT-generated  planview  information  superimposed  on  a 
color  film  projected  moving  map  for  navigation,  updating,  and  sensor  correlation. 


PROBLEM 

•  HIGH  WORKLOAD  ITEMS 

-  WEAPONS/SENSORS 

-  CNI 

-  MODING 


anunM 


FIGURE  3 

COCKPIT  INTEGRATION 


The  three  CRT  displays  use  a  MENU  concept,  Figure  a,  to  take  advantage  of  software  flexibility  in 
the  orientation  of  switches.  As  shown,  the  various  modes  have  computer-driven  submode  nomenclature  which 
becomes  available  when  needed. 

The  left  and  right  hand  displays  are  Identical.  Each  contains  the  symbol  generators  capable  of 
driving  up  to  two  other  displays  (HUD  and  HI)  depending  upon  mode  complexity.  Additionally,  mission 
computer  display  management  software  has  been  designed  so  that  the  control/display  functions  of  the 
left/right  displays  are  Interchangeable,  allowing  all  of  their  functions  to  be  selected  on  either  display 
In  flight. 

The  Hornet  Hands-on-Thtottle-and-Stick  (HOTAS)  concept  provides  computer  assigned  switches  for 
weapon  and  sensor  control  during  high  "g"  maneuvering  and  for  time  critical  functions  while  maintaining 
full  control  of  the  aircraft.  The  HOTAS  concept  allows  the  pilot  to  perform  complete  visual  and  sensor 
aided  gun  and  missile  attacks,  from  target  detection  through  weapon  delivery  without  removing  his  hands 
from  the  stick  or  throttle.  Similar  functions  are  performed  for  alr-to-surface  attack. 

The  Target  Designator  Control  (TDC)  on  the  throttle  is  a  force-sensitive  switch  which  slews  the 
sensor  seekers  and  display  designator  symbol  In  any  direction.  Designation  is  accomplished  by  pressing 
and  releasing  the  TDC  switch.  The  TDC  can  also  be  used  to  select  radar  parameters  such  as  mode,  scan, 
azimuth  and  range  scales. 


A/Q  PROGRAM  MODE  WILL 
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MENU  CONCEPT 


The  Up-Front  Control  (UFC)  panel  provides  computer  aided  head-up  control  of  the  two  UHF/VHF  radios, 
ILS,  Data  Link,  TACAN,  Beacon,  ADF,  IFF  and  auto-pllot  modes.  The  panel  is  mounted  on  the  front  face  of 
the  HUD  electronics  unit  within  easy  reach  of  either  hand. 

Radar/Attack  Sensors  -  The  principle  sensor  of  the  F/A-18  weapon  system  for  both  fighter  and  attack 
missions  Is  the  Hughes  AN/APG-65  multimode  radar.  This  radar  provides  better  weapon  delivery  performance 
than  the  A-7  and  surpasses  the  F-A  radar  In  the  fighter  role.  The  radar  satisfies  these  performance 
objectives  at  half  the  weight  and  volume,  with  four  times  the  reliability  of  the  F-4J  radar.  Its 
versatility  Is  Illustrated  by  the  air-to-air  and  alr-to-surface  modes  which  Include; 

Alr-to-Alr  Alr-to-Surface 

o  Velocity  Search  o  Real  Beam  Ground  Map 

o  Range  While  Search  o  Doppler  Beam  Sharpening  (DBS) 

o  Track  While  Scan  o  Ground  Moving  Target  Indication/Track 

o  Raid  Assessment  o  Fixed  Target  Track 

o  Air  Combat  Maneuvering  (ACM)  o  Terrain  Avoidance 

-  Boreslght  o  Sea  Surface  Targeting 

-  HUD  o  Alr-to-Ground  Ranging 

-  Vertical  o  Precision  Velocity  Update 

-  Gun  Acquisition 

o  Special  Short  Range  Track 

The  key  to  the  radar's  flexibility  Is  Its  high  speed  programmable  processors  and  large  (156K)  disc 
memory.  Software  programs  for  all  the  modes  are  stored  on  the  disc  memory.  When  a  different  mode  Is 
selected  by  the  pilot  during  flight,  the  associated  software  program  Is  transferred  to  the  operating 
memories  In  the  radar  signal  and  data  processors.  The  programmable  processors  combined  with  the  large 
memory  capacity  will  accommodate  new  radar  modes  and  provide  an  adaptive  ECCM  capability  well  Into  the 
future. 

In  addition  to  the  multimode  radar,  a  Forward  Looking  Infrared  Set  (FLIR)  and  a  Laser  spot  Tracker 
(LST)  are  employed  for  the  light  attack  role.  With  these  Integrated  attack  sensors,  the  F/A-18  offers 
better  navigation,  target  location,  track  capability  and  delivery  accuracy  than  any  existing  fighter/ 
attack  system. 

The  FLIR  has  3*  and  12*  fields  of  view  and  a  fleld-of-regard  which  covers  all  nonshadowed  aircraft 
regions  other  than  a  30*  cone  at  the  tall  of  the  aircraft.  It  has  the  capability  both  for  self-tracking 
and  being  cued  by  the  radar  or  navigation  system. 


The  LST  automatically  searches  out  and  tracks  targets  being  illuminated  by  a  forward  controller  or 
an  airborne  illuminator.  Search  patterns  for  the  8°  FOV  seeker  include  a  +20°  azimuth  scan  and  a  HUD 
f ield-of-view  scan. 

A  Strike  Camera,  installed  in  a  rotary  mount  at  the  rear  of  the  LST  pod,  is  computer  directed  and 
photographs  the  target  area  as  the  aircraft  egresses. 

Stores  Management  -  The  stores  management  functions  are  handled  by  a  digital  processor  and 
individual  stores  decoders  located  at  the  external  store  stations.  This  design  approach,  which  uses  a 
dedicated  multiplex  bus  to  pass  information  between  the  processor  and  the  decoders,  minimizes  the 
traditional  weight  penalty  resulting  from  large  quantities  of  armament  wires  over  long  routing  paths. 
Additionally,  armament  changes  can  ordinarily  be  accommodated  by  interface  modifications  in  the  decoders 
and  software  changes  in  the  processor,  eliminating  the  need  for  difficult  wiring  retrofits. 

Flight  Control  -  To  provide  good  handling  qualities  throughout  its  wide  range  of  flight  conditions, 
Including  the  demanding  carrier  landing  phase,  the  F/A-18  incorporates  a  digital,  quad-redundant 
control-by-wire  flight  control  system.  The  Flight  Control  Electronics  Set  computes  aircraft  stability 
and  handling  qualities  for  each  phase  of  flight.  Its  four  channels  of  digital  electronics  and  sensors 
assure  "fail-operational"  performance  and  are  backed  up  by  direct  electrical  and  direct  mechanical  link 
modes.  Integrated  pilot  assist  (autopilot)  modes  include:  heading  select,  heading,  attitude,  speed  and 
barometric  or  radar  altitude  hold,  traffic  control  and  automatic  carrier  landing,  approach  power 

compensation,  and  vector  and  precision  course  direction  combat  modes. 

CN1  -  Primary  cockpit  control  of  the  CN1  equipment  is  performed  from  the  Up-Front  Control  Panel. 
Memory  and  software  control  for  these  functions  resides  in  the  programmable  communication  system  control 
unit. 

Voice  consnunication  is  provided  by  the  two  new  ARC-182  UHF/VHF  -  AM/FM  transmitter-receivers.  These 
are  integrated  with  the  KY-58  crypto  computer  for  secure  voice  and  with  the  direction  finding  set  for 
navigational  bearings.  The  intercom  set  provides  for  voice  communication  with  ground  maintenance 
personnel  and  the  rear  crewman  of  the  two  seat  trainer,  as  well  as  providing  preprogrammed  voice  messages 
for  alerting  the  pilot  of  critical  information. 

Radio  navigational  systems  include  the  AN/ARN-118  TACAN,  AN / ARA-63  1LS,  AN/APN-202  beacon, 

R-1623/APN  receiver,  AN/APN-194  radar  altimeter  and  RT-1379/ASW  two  way  data  link. 

TACAN  range  and  bearing  are  used  in  the  mission  computer  to  compute  steering  to  any  selected 

waypoint  or  target,  in  addition  to  the  TACAN  station. 

The  data  link  provides  airborne  target  designation,  vectoring  and  handoff.  Data  link  transfer  of 
Initial  Inertial  alignment  and  waypoint  insertion  data,  and  guidance  signals  for  automatic  carrier 
landing  are  available  from  the  aircraft  carrier. 

Self-identification  is  accomplished  by  the  AN/APX-100  IFF  Set  with  crypto  capability  provided  by  the 
K1T-1A/TSEC  equipment. 

Navigation  -  The  AN/ASN-130  is  the  primary  kinematic  sensor  in  the  F/A-18.  Navigation  performance 
during  flight  test  was  0.6  nm/hr  CEP.  Its  outputs  include  aircraft  attitude,  attitude  rates,  heading, 
velocity,  acceleration,  and  latitude/longitude.  These  signals  are  integrated  throughout  the  weapon 
system  for  accurate  navigation,  air-to-surface  weapon  delivery,  radar  velocity  augmentation  and  lead 

computing  gunnery.  The  air  data  system  provides  backup  navigation  and  primary  flight  aids  data  for 
flight  control  scheduling  and  cockpit  display.  Navigation  updates  are  available  from  TACAN,  radar,  FL1R 
and  visual  offset  or  overflight. 

Electronic  Warfare  -  The  EW  Suite  consists  of  the  new  technology  AN/ALR-67  Radar  Warning  Receiver 
currently  in  development  by  the  Navy,  an  internal  AN/ALQ-126  ECM  Jammer,  and  the  AN/ALE-39  dispenser  for 
releasing  chaff,  IR  flares  and  active  RF  devlcea. 

Reliability  and  Maintainability  -  The  most  capable  systems  in  the  world  are  worth  little  if  they 
fail  too  often  and  are  time  consuming  to  maintain. 

Five  basic  strategies  are  employed  to  Increase  system  reliability.  These  are  to:  standardize  and 
reduce  the  number  of  equipments  and  components;  design  and  manufacture  reliability  into  each  equipment; 
provide  an  aircraft  environment  less  likely  to  cause  equipment  failure;  test  equipment  to  the  actual 
operational  mission  environment,  and  operate  the  equipment  only  when  necessary. 

Resulting  reliability  characteristics  include: 

o  A  3:1  reduction  in  control/display  units 
o  Use  of  the  INS  for  the  lead  computing  alght  functions 

o  Cool  ECS  air  (*0°F  maximum)  dried  by  a  high  pressure  water  separator  for  lower  unit  temperatures 
o  An  automatic  avionics  ground  cooling  fan,  with  thermal  interlock 

o  A  reduction  of  avionics  ground  operation  by  functionally  isolated  electrical  power  circuits 
o  Derating  of  component  temperature  and  power  requirements,  even  below  NASA  space  requirements 
o  Stringent  parts  selection  and  screening 
o  More  efficient  heat  extraction  designs 

o  Critical  equipment  tested  to  operational  mlasion  environment 

Initial  proof  of  the  success  of  the  reliability  design  was  obtained  in  the  100  flight  hour 
reliability  demonstration  flown  In  November  1981  at  NATC,  Patuxent  River.  Maryland,  on  the  11th  F/A-18 
Hornet.  During  this  demonstration  milestone,  in  which  a  variety  of  typical  fighter/attack  missions  were 
flown,  only  three  avionics  failures  occurred.  The  radar  did  not  fall  during  this  test.  Mean  flight 
hours  between  failures  for  the  complete  aircraft  were  8. A,  versus  the  specification  guarantee  of  3.7 
hours. 
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Combining  high  reliability  with  the  Hornet's  new  maintenance  features  make  It  the  most  supportable 
aircraft  ever  Introduced  to  the  fleet.  The  time  and  effort  to  correct  a  defective  subsystem  on  the 
Hornet  are  significantly  reduced  by  the  high  capability  Built-in-Test  (BIT)  system  and  a  tremendous 
improvement  in  box  accessibility.  89Z  of  the  units  are  at  chest  height  and  none  are  hidden  behind 
others.  The  comprehensive  avionic  BIT  system  is  designed  for  failure  detection  to  982  and  fault 
Isolation  to  99Z.  Cockpit  control  and  display  status  on  the  left  hand  multifunction  display,  is  avail¬ 
able  both  in  flight  and  on  the  ground.  To  enable  the  pilot  to  assess  the  ability  to  complete  a  mission, 
eifMptue-  t  UfelftetoLfll  HA&hio*  AuJ  Ufcmnp  ibu&>  Mi  ate 

The  Maintenance  Monitor  Panel,  located  in  the  nose  wheel  well,  has  142  avionic  Weapon  Replaceable 
Assembly  discrepancy  codes  which  cue  the  maintenance  crew  to  the  proper  aircraft  access  door  and  to 
failed  components.  Additionally,  there  are  116  MMP  discrepancy  codes  for  engine  and  air-vehicle 
components  and  12  servicing  codes  for  hydraulics,  fluids,  structural  overstress  and  tape  recorder  reload. 

Other  cost-reducing  maintenance  capabilities  include  the  Maintenance  Signal  Data  Recorder,  which 
records  engine  data  and  airframe  structural  fatigue  cycles  on  a  readily  removable  tape  cassette, .  and  the 
Electronic  Boresight  Unit,  which  allows  dialing  in  boresight  compensation  to  the  computers  in  place  of 
traditional  mechanical  shimming. 

THE  KEY  FEATURE  FOR  TODAY  AND  TOMORROW 


The  purpose  of  the  F/A-18  weapons  system  is  to  minimize  sorties  per  kill.  This  requires  accurately 
and  reliably  delivering  air-to-air  and  air-to-ground  weapons  on  targets  that  must  be  detected,  identi¬ 
fied,  acquired  and  tracked  by  the  pilot  using  smart  weapons  and  sensors.  The  key  to  modern  avionics  is 
computer  technology;  and  the  key  to  avionics  computer  technology  in  the  F/A-18  is  the  integration  of  the 
data  processing.  The  pilot,  in  addition  to  flying  the  aircraft,  must  monitor  the  instruments  to  ensure 
that  the  weapon  system  can  accomplish  its  purpose.  Every  decision  that  could  be  safely  removed  from  the 
pilot's  tasks  is  performed  by  the  highly  integrated  computational  subsystem.  This  subsystem,  as  shown  in 
Figure  5,  consists  of  two  mission  computers  and  peripheral  computers  in  sensor  and  display  equipment. 
The  airborne  computational  tasks  are  divided  into  two  general  categories,  e.g.,  sensor  oriented 
computations  and  mission-oriented  computations. 

Sensor-oriented  computations  are  those  such  as  sensor  coordinate  transformations,  platform 
management  and  signal  processing,  which  are  peculiar  to  a  particular  sensor  or  display.  They  are 
tA  wu**«im!  sc  ai  jcinjna  kl ■  dupalil  i  Ml  a,  cs  lauerl 

calculations,  are  related  directly  to  performing  the  mission  and  depend  on  information  from  several 
avionics  subsystems.  Mission-oriented  computations  are  performed  in  two  mission  computers. 
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The  design  approach  provides  functional  modularity  of  the  sensors  and  integration  by  the  mission 
computers.  Benefits  offered  by  this  architecture  include  a  high  degree  of  parallel  processing  capabil¬ 
ity,  avoiding  unnecessarily  high  speeds  in  any  one  processor;  simplification  of  subsystem  interfaces  in 
ifTunlliy  and  Ma;  mattes  ant  der&kpoetrt  <4  the  inlsgtatei  nbftit  li  -penile!  eii', 
the  subsystems;  clear  division  of  system, 'subsystem  responsibility  and  effective  use  of 
englneering/manufacturing  expertise;  simplification  of  maintenance  through  functional  modularity;  and 
ease  of  growth. 

Sensor-Oriented  Processing  -  There  are  four  major  subsystem-embedded  reprogrammable  computers  and  a 
number  of  smaller  subsystems  with  embedded  microprocessors  with  read-only  memories  (ROM).  Each  sensor 
computer  performs  only  those  computations  necessary  for  that  sensor  to  perform  its  well-defined  task. 
This  includes  all  computations  required  to  translate  some  measured  physical  parameter,  such  as  air 
pressure,  into  useful  information  for  the  pilot,  such  as  altitude,  air  speed,  and  Mach  number.  Once  the 
information  is  computed,  it  is  sent  to  the  mission  computer  over  the  avionics  multiplex  bus.  There  it  is 
used  with  information  from  other  sensors  to  perform  the  mission-oriented  computations  as  well  as  for 
display  to  the  pilot. 

Mission  Computer  Processing  -  The  mission  computer  (MC)  subsystem  consists  of  two  identical  U.S. 
Navy  Standard  Airborne  Computers  designated  AN/AYK-14.  Although  the  hardware  of  the  two  computers  is 
identical,  their  computer  programs  are  different  and  are  dedicated  to  specific  processing  tasks.  The 
AN/AYK-14  is  a  high  speed,  general  purpose  digital  computer  specifically  designed  to  meet  the  real-time 
re  uirements  of  an  airborne  weapon  sjstem,  while  retaining  coirpatibilitl  with  existln  higher  order 
language  support  software.  Each  computer  was  originally  delivered  with  a  memory  capacity  of  64K  16  bit 
words,  but  this  capability  is  being  increased  to  128K  by  inserting  physically  interchangeable  double 
density  memory  modules.  Each  mission  computer  is  dedicated  to  specific  processing  tasks  by  means  of  its 
stored  program.  One  computer  is  assigned  the  navigation  and  support  processing  tasks  and  associated 
display  management.  The  other  computer  is  assigned  the  air-to-air  and  air-to-ground  weapon  delivery 
processing  tasks  and  associated  display  management.  Each  computer  has  a  small  back-up  software  module 
for  selected  functions  of  the  other  computer.  The  navigation  computer  has  a  small  weapon  delivery 
back-up  software  module  and  the  weapon  delivery  computer  has  a  small  navigation  back-up  software  module. 
These  back-up  modules  are  executed  only  in  the  event  the  primary  computer  for  these  functions  should 
fail. 


F/A-18  Avionics  Multiplex  System  -  Digital  data  between  the  Mission  Computers  and  the  peripheral 
avionics  components  is  transferred  on  the  MC-controlled  Avionics  Multiplex  system.  The  system  consists 
of  three  multiplex  channels.  Each  channel  consists  of  two  redundant  1  MHz  MIL-STD-1553A  data  buses,  each 
operated  in  a  half-duplex  fashion.  All  peripheral  units  on  a  single  channel  are  connected  to  the 
transmission  lines  comprising  that  channel  in  parallel,  party-line  fashion,  such  that  physical  removal  of 
a  unit  from  the  lines  does  not  interrupt  the  continuity  of  the  lines.  All  units  on  the  same  channel  see 
all  of  the  data  on  that  pair  oi  buses.  However,  on  a  given  channel,  data  is  transferred  only  between  the 
MC  and  a  single  peripheral  at  a  time.  Each  bus  is  independently  routed  through  the  aircraft  to  ensure 
reliable  communication  in  the  event  of  damage.  Only  one  of  the  buses  of  each  redundant  pair  is  active  at 
any  one  time.  The  MC  selects  which  of  the  data  buses  is  to  be  used  for  data  transmission  and  initiates 
each  data  exchange  over  the  selected  bus.  The  mission  computers  include  independent  controllers  for  each 
of  the  multiplex  channel*  permitting  full  use  of  the  computer  for  processing  tasks  during  input/output. 
Control  of  the  multiplex  system  is  transferred  between  the  two  MCs  based  on  priority  of  need. 

Integration  Flexibility  -  The  combination  of  central  mission  computers  and  distributed  processing  in 
the  peripheral  computers  that  comprise  the  various  subsystems  gives  the  F/A-18  a  powerful  integration 
flexibility.  As  shown  in  Figure  6,  the  Individual  sensors  with  their  special  processors  are  readily 
integrated  via  the  multiplex  lines  and  the  central  computer.  The  addition  of  new  sensors  is  accomplished 
bjr  adding  Wte  -vTt.jltT  ,.rtj  tie  T.  pi-oe ... Ssut  -tv  th-  rualtiplaX:  bos  and  P rugT&uiilii trg  ffi'  aitsltufr 
computer  to  provide  the  required  integration  functions. 
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ENHANCEMENTS  UNDERWAY 


The  built-in  flexibility  of  the  F/A-18  avionics  system  permits  a  wide  range  of  enhancements  to  be 
readily  incorporated  Into  the  basic  airplane. 

ASPJ  -  The  Airborne  Self  Protection  Jammer  is  the  newest  countermeasure  equipment  being  developed  by 
the  U.S.  Navy  for  joint  Navy  and  Air  Force  use.  The  ASPJ  is  a  modular,  sof tware-controlle'd  system  that 
is  electrically  reprogrammable  to  enhance  ASPJ’s  ability  to  counter  the  existing  and  future  threats  with 
minimal  impact  on  cost.  It  provides  more  effective  and  sophisticated  pulse  and  CW  jamming  of  radar 
threats.  As  shown  in  Figure  7,  installation  and  integration  are  especially  easy  on  the  F/A-18.  Internal 
mounting,  cooling,  waveguide  routing  and  antenna  placement  are  already  available,  and  no  new  equipment 
bay  design  is  required. 


ANfALQ-126  AN/ALQ-165  (ASPJ) 

NO  COMPLEX  REDESIGN  REQUIRED  FOR: 

•  UNIT  LOCATION 

•  MOUNTING  ARRANGEMENT 

•  COOLING  AVAILABILITY 

•  WAVE  GUIDE  ROUTING 
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•  ANTENNA  REPLACEMENT 
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HORNET  IS  CONFIGURED  FOR  ADVANCED 
INTERNAL  ECM 


JTIDS  -  The  Joint  Tactical  Information  Distribution  System  will  provide  secure,  jam  resistant, 
digital  data  and  voice  communication.  This  will  significantly  enhance  combat  control,  surveillance,  air 
traffic  control  and  information  management  as  well  as  provide  an  inherent  precise  location  and 
identification  capability.  Current  plans  call  for  the  Hornet  to  be  the  first  USN  airplane  to  receive 
JTIDS  and  701  of  the  USN  aviation  terminals  are  scheduled  for  Hornets.  Since  JTIDS  is  a  digital  data 
link,  its  introduction  into  the  digital  Hornet  is  significantly  simplified. 

AMRAAM  -  The  Advanced  Medium  Range  Air-to-Air  Missile  development  program  is  underway.  Missile 
integration  on  the  Hornet  is  facilitated  by  the  existing  multiplexed  armament  data  bus,  the  current 
capability  of  the  airplane  to  csrry  AIM-7F  Sparrow  missiles  and  current  availability  of  complementary 
radar  modes.  Controls,  displays,  and  lsunch  and  steering  computations  require  only  software  changes  for 
AMRAAM  compatibility. 

LTD/R  -  The  laser  target  designator/ ranger,  which  will  be  installed  in  reserved  space  In  the  Forward 
Looking  Infrared  (FUR)  Detecting  Set,  AN/AAS-38,  provides  a  self-contained  laser  with  autonomous 
designation  and  ranging  capability.  Inherent  advantages  are  a  more  effective  means  of  designating 
targets,  decreased  vulnerability  of  pilots  and  aircraft.  Increased  mission  flexibility  and  increased 
number  of  targets  attacked.  Vulnerability  of  pilots  and  aircraft  is  reduced  because  no  need  exists  for 
coordination  either  with  a  less  maneuverable  designator  aircraft  or  a  more  vulnerable  ground  designator. 
Increased  mission  flexibility  results  from  autonomous  designation  since  the  attack  aircraft  has  more 
freedom  to  choose  approach  and  maneuver  tactics  over  the  target  area  without  rendezvous-imposed 
constraints. 

Improved  Radar  Resolution  -  The  production  radar  Doppler  Beam  Sharpened  (DBS)  mapping  capability  is 
being  expanded  to  extend  the  range  of  the  existing  67:1  DBS  mode  by  a  factor  of  five.  It  is  a  measure  of 
the  Inherent  capacity  of  the  radar  that  this  change  is  accomplished  entirely  in  software.  This  change  is 
currently  in  flight  test. 

Tactical  Reconnaissance  -  As  the  f lghter/attack  Hornet  is  being  introduced  to  fleet  service,  the 
Naval  Air  Development  Center  and  McDonnell  Douglas  are  developing  a  third  mission  role  capability  for  the 
Hornet:  Tactical  Reconnaissance.  An  engineering  test  bed  demonstrator  is  scheduled  to  fly  in  early 
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1984,  combining  the  Hornet's  existing  air  vehicle  performance,  flight  control,  sensor,  and  cockpit 
display  capabilities  with  traditional  reconnaissance  sensors.  The  RF/A-18  Engineering  Test  Bed  will 
integrate  tactical  reconnaissance  capabilities  into  the  existing  fighter/attack  weapon  system  with 
minimal  change  in  P/A-18  performance  or  capability. 

This  initial  reconnaissance  capability  is  achieved  by  temporary  gun  removal  and  substitution  of  a 
reconnaissance  equipment  pallet.  A  mix  of  sensors  can  be  installed  on  this  pallet  to  obtain  frame, 
panoramic  or  infrared  line  scan  imagery,  depending  on  light,  weather,  overflight  altitude,  standoff  range 
and  the  mission  objective.  These  sensors  can  be  operated  automatically  and  are  further  augmented  by  the 
excellent  imagery  provided  by  the  F/A-18's  current  production  radar  and  forward  looking  infrared  (FLIR) 
set.  Near-real-time  digital  data  is  made  available ■ through  the  Hornet's  current  data  link.  As  an  aid  to 
the  pilot,  a  ground  track  hold  mode  will  be  added. 

In  addition  to  the  Hornet's  multimode  radar  real  beam  ground  map,  other  air-to-surface  modes  are 
readily  usable  for  reconnaissance  missions.  The  radar  detects  and  locks  onto  moving  and  fixed  targets; 
detects  ships  using  a  sea  search  mode;  generates  a  display  for  low  altitude  terrain  avoidance;  and 
displays  Doppler  beam  sharpened  (DBS)  imagery  that  provides  either  a  19:1  or  67:1  azimuth  resolution 
enhancement  over  real  beam  ground  map.  The  extended  range  resolution  improvement  will  provide  resolution 
enhancement  at  longer  ranges  without  hardware  changes. 

The  AN/AAS-38  FLIR,  developed  for  the  attack  Hornet,  also  is  planned  for  use  in  reconnaissance 
missions.  Its  aimable  high  resolution  Infrared  sensor,  with  a  large  field-of-regard,  covers  essentially 
the  entire  lower  hemisphere. 

Link  4,  normally  used  for  intercept  control,  can  be  used  on  reconnaissance  missions  to  transmit 
target  data  including  both  position  and  identification  messages. 

The  RF/A-18,  shown  in  Figure  8,  is  capable  of  substantial  growth  to  provide  high  resolution  radar, 
long  standoff  operation  and  real  time  imaging  data  link. 


FIGURE  8 

RECONNAISSANCE  SENSOR  AND  EQUIPMENT  ARRANGEMENT 


Conversion  to  fighter  or  attack  roles  requires  only  the  time  it  takes  to  rearm  the  aircraft, 
eight  hours  are  needed  if  it  is  desired  to  refit  the  gun. 


About 


Attack  Enhancements  -  Modifications  such  as  those  illustrated  in  Figure  9  are  being  investigated  for 
increasing  the  weapon  system  utility  and  effectiveness  and  increasing  survivability.  To  expand  the 
weapon  system  utility,  day/nlght,  low  level  navigation  sensors  are  being  evaluated.  Conmunications  and 
battle  area  awareness  will  be  enhanced  by  JTIDS.  Precision  navigation  systems,  very  high  resolution 
radar  and  automatic  target  recognition  technology  will  increase  the  probability  of  detecting  and 
recognizing  the  targets.  These  sensors  and  new  weapon  delivery  algorithms  will  permit  manual  or  coupled 
maneuvering  (non-wings  level)  attack  day/night  and  in  adverse  weather  with  a  high  probability  of  target 
kill  and  aircraft  survivability. 


| 
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Cockpit  enhancements  will  include  additional  integration  of  threat  warning  and  ECCM  features, 
installation  of  wide  field-of-view  raster  HUD  and  color  displays,  and  higher  levels  of  automation.  The 
wide  field  of  view  HUD,  illustrated  in  Figure  10,  provides  data  display  and  cueing  information  to  the 
pilot  while  remaining  head-up  without  cluttering  the  central  flight  presentations.  Raster  compatibility 
permits  the  display  of  WFOV  FLIR  imagery  for  low  level  navigation.  To  provide  up  front  control 
capability  while  providing  more  flexible  display  area,  interactive  flat  panel  displays  with  raster 
capability  will  be  pursued.  The  interactive  flat  panel  provides  the  needed  central  display  of  threat 
warning  data  and  provides  a  flexible  control  panel  for  management  of  sensors  and  missionized  avionics 


FIGURE  10 

WIDE  FIELD-OF-VIEW  HEAO  UP  OISPLAY 
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packages.  The  option  for  a  dedicated  weapons  system  operator  station  is  also  available  to  extend  attack 
system  capability  into  a  more  hostile  environment.  The  weapon  system  operator  station  will  have  display 
formats  independent  of  those  selected  in  the  front  and  will  have  a  sensor  display  optimized  in  size  for 
the  high  resolution  sensors.  Simultaneous  operation  of  selected  radar  modes  is  planned,  with  the  radar 
modified  to  provide  two  concurrent  displays. 

L  ■  "  , 

Pw mtm  r  a*  Mi<#i*n  fc  ,fini  >r  alU  k  ■(  (rf  - 
Maverick  and  mine  capability. 

SIMULATION 

All  of  the  enhancements  described  above  are  already  being  flown  or  evaluated  by  pilots  in  MCAIK's 
Manned  Air  Simulation  facility.  The  facility  permits  system  functional  integration  on  a  scale  and  with  a 
fidelity  not  otherwise  available.  It  is  a  unified  laboratory  complex  oriented  primarily  toward,  but  not 
limited  to,  manned,  real-time  flight  simulation.  It  is  comprised  of  a  dedicated  computer  complex,  six 
c.rew-stations  (five  fixed  base  and  one  motion  base),  terrain  maps,  horizon  displays,  airborne-  target 
displays,  and  associated  hardware.  This  facility  offers  a  wide  range  of  flexibility,  emphasizing  the 
goal  of  achieving  efficient,  low  cost  and  accurate  simulations  of  modern  aircraft  systems.  The  core  of 
the  flight  simulation  laboratory  is  a  Control  Data  Corporation  (CDC)  CYBER  760U  digital  computer.  Active 
primary  and  secondary  flight  controls  and  active  flight  instruments  are  provided.  "G"  effects  are 
provided  by  "G"  suits,  "G”  cushions  and  blackout  simulation.  Sound  cues  of  gun  firing,  missile  launches, 
engine  rpm,  afterburner,  speedbrake,  skin  noise,  wind  over  canopy,  flaps,  landing  gear,  buffet,  tire 
contact  and  runway  rumble  are  provided.  Radar,  HUD’s  and  other  special  displays  and  controls  are 
provided  as  required.  This  highly  integrated  system  provides  central  software  control  for  any  simulation 
problem.  It  is  used  to  evaluate  avionics  systems,  flight  controls,  cockpit  arrangement  and  displays, 
fighter  gun  and  missile  effectiveness,  and  to  develop  new  tactics  for  fighter  aircraft. 

MCAIR's  simulation  approach  is  to  apply  simulation  techniques  in  all  phases  of  weapons  system  (or 
subsystem)  design  from  concept  through  deployment.  The  F/A-I8  aircraft  was  totally  simulated  long  before 
the  first  flight.  MCAIR  and  customer  pilot's  "hands-on"  experience  of  flying  in  the  simulator,  Figure 
11,  permits  user  inputs  early  in  the  design  phase.  The  result  is  significantly  lower  development  cost 
with  substantially  higher  operational  effectiveness  and  utilization  than  could  be  achieved  by  other 
development  techniques. 


FIGURE  11 
FLIGHT  SIMULATOR 
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CONCLUSION 

The  F/A-I8,  Figure  12,  provides  unique  capability  in  its  digital  avionics  and  high  degree  of 
integration.  When  combined  with  the  engineering  resources  of  modern  software  and  simulation  facilities, 
the  significant  growth  potential  can  be  exploited.  These  programs  are  under  way. 


ADVANCED  TECHNOLOGY  TODAY 


. and  TOMORROW 
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DISCUSSION 


J .Mitchell,  UK 

Are  you  considering  installation  of  NAVSTAR/GPS  in  the  F-l  8? 

Author’s  Reply 

Yes.  USN  has  been  told  how  much  it  would  cost.  We  are  awaiting  a  decision. 


R.Davies,  Ca 

(1)  F-14  has  recently  introduced  a  Beyond  Visual  Range  Daylight  Visual  TV  Sight  Unit.  Why  not  on  USN  F-l 8? 

(2)  USMC  traditionally  want  close  attack  aircraft  close  to  their  beachhead  or  FEBA.  How  do  they  achieve  a  quick 
response  with  the  F-l 8  INS? 

Author’s  Reply 

(1)  The  US  Navy  has  not  identified  a  need  for  a  beyond  visual  range  daylight  sight  system  in  the  F/A-18A. 

(2)  The  F/A-18A  INS,  the  AN/ASN-1 30,  provides  attitude  heading  reference  (AHRS)  data  within  30  seconds  of 
tum-on.  The  aircraft  can  fly  all  A/A  and  most  A/G  missions  on  AHRS  data  only.  If  the  aircraft  has  not  been 
moved  since  shutdown  (stored  heading)  the  INS  will  be  fully  aligned  in  4  minutes.  Otherwise,  the  full  gyro 
compass  alignment  time  is  six  minutes. 

J.O.Vaillancourt,  Ca 

Is  the  FL1R  the  Ford  Aerospace  system?  Is  it  in  production  to  be  procured  by  the  USN? 

Author’s  Reply 

The  AN/AAS-38  FLIR  subsystem  is  built  under  contract  to  MCAIR  by  Ford  Aerospace  with  Texas  Instruments 

being  the  major  subcontractor  for  common  module  IR  components.  The  first  production  lot  purchase  order  was 

placed  May  1982  with  the  first  production  unit  scheduled  for  delivery  to  the  US  Navy  on  1  April  1984. 
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DEF  STAN  00-18:  A  FAMILY  OF  COMPATIBLE  DIGITAL  INTERFACE  STANDARDS 


by 

D.  R.  Bracknell 
& 
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Royal  Aircraft  Establishment 
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GUI 4  6TD 
United  Kingdom 


The-^aper  discusses  the  results  of  work  undertaken  by  the  joint  MOD(PE) /Industry  Data  Transmission 
Standards  Comnittee  (DTSC)  in  the  formulation  and  promulgation  of  UK  Defence  Standard  techniques  for  digi¬ 
tal  interfaces  in  aircraft  systems. 

.  - - - 

Four  data  transmission  standards  prepared  by  the  DTSC  have  now  been  published  iy-M0II  as  parts  of 
DEF  STAN  00-18,  and  these  are  described.  They  constitute  a  compatible  family  of  standards  for  avionic  data 
transmission  to  meet  the  majority  of  current  system  requirements,  and  have  served  to  focus  both  component 
and  system  development  resources  within  the  UK,  to  the  benefit  of  both  MOD  and  Industry.  The  paper  touches 
or.  the  associated  Sub-conmittee  activity  within  DTSC,  and  the  guide  to  the  use  of  the  standards  which  has 
been  published  as  Part  I  of  the  DEF  STAN.  It  concludes  with  a  discussion  of  future  plans  and  new  options 
for  standardisation.  < 


1  INTRODUCTION 

There  is  an  ever-present  need  for  standardisation,  particularly  in  the  case  of  military  equipment, 
where  there  is  a  prime  aim  to  reduce  development,  acquisition  and  life-cycle  costs  and  to  improve  inter¬ 
operability.  Rapid  changes  in  technology,  however,  often  conflict  with  this  objective  with  the  result 
that  either  the  standards  quickly  become  obsolescent  or  they  suffer  the  accusation  of  stultifying  techno¬ 
logical  progress. 

One  way  around  this  problem  is  to  look  for  standardisation  initiatives  at  interfaces,  both  physical 
and  conceptual,  and  in  the  airborne  data  transmission  field  at  present  near  ideal  conditions  exist  for 
standardisation.  This  is  because  overall  data  transmission  requirements  for  current  and  near-future 
systems  are  reasonably  static  in  terms  of  such  things  as  bandwidth,  iteration  rates,  and  so  on.  There  is 
also  a  genuine  desire  by  all  parties  involved,  suppliers  and  customers  alike,  to  co-operate  in  finding 
acceptable  technical  solutions  to  the  problem. 

This  paper,  then,  describes  the  formulation  of  the  joint  MOD(PE)/Industry  Data  Transmission  Standards 
Committee  (DTSC),  and  the  co-operative  efforts  which  have  resulted  in  defining  the  requirements,  producing 
and  supporting  the  DEF  STAN  00-18  series  of  standards,  the  vehicle  for  airborne  data  transmission 
standardisation. 

2  THE  DATA  TRANSMISSION  STANDARDS  COMMITTEE  (DTSC) 

Within  the  UK,  Industry  and  Government  views  on  avionics  systems  research  are  established  by  the  Joint 
Committee  for  Avionic  Systems  Research  (JCASR).  Industry  is  represented  by  the  Electrical  Engineering 
Association  (EEA)  in  conjunction  with  the  Society  of  British  Aerospace  Companies  (SBAC),  and  the  Government 
by  MOD(PE),  the  Department  of  Industry  and  the  Civil  Aviation  Authority. 

In  1973,  under  the  auspices  of  a  then  existing  liaison  group  of  JCASR,  a  Digital  Interfaces  Sub  Group 
(DISG)  was  formed  to  specifically  look  at  the  requirements  for  airborne  data  transmission  and  recommend, 
where  possible,  the  formulation  of  standards  for  digital  interfaces,  primarily  external  to  equipment. 

By  1977,  a  list  of  six  classes  of  interface  had  been  identified  and  draft  recommendations  had  been 
produced.  The  classes  were  as  follows: 

single-source,  single-sink 
single-source,  multi-sink 
multi-source,  mult;-sink 
duplex  serial  link 
discrete  signalling 
byte-oriented  point-to-point  link. 

The  DISG,  however,  was  a  voluntary  association  of  Industry,  with  no  financial  resources  to  undertake 
the  detailed  specification  and  drafting,  and  with  no  formal  links  to  the  MOD  Directorate  of  Standardisation 
(D  STAN).  At  this  point  the  MOD  Directorate  of  Air  Navigation  and  Reconnaissance  (DA  Nav)  and  RAE  Flight 
Systems  Department  took  a  joint  initiative  to  establish  a  new  body  to  take  over  the  formulation  of  inter¬ 
face  standards.  It  would  be  funded  by  MOD(PE)  to  provide  adequate  agency  and  secretarial  support,  and 
would  be  capable  of  producing  draft  standards  to  the  requiresMnts  of  D  STAN  as  well  as  providing  a  dedica¬ 
ted  test  house  capability  for  EMC  trials. 


Thus  the  DTSC  uas  formed  in  1978,  under  the  chairmanship  of  DA  Nav  and  with  RAE  acting  as  Technical 
Authority.  It  comprises  a  main  comnittee  together  with  a  number  of  sub-committees  or  working  groups,  each 
dealing  with  a  particular  specialist  area.  Committee  and  working  group  membership  is  open  to  any  organ¬ 
isation  concerned  with  the  design,  development  or  construction  of  data  transmission  systems.  ERA  Technology 
Ltd  are  funded  to  act  as  the  DTSC  agency,  providing  the  secretariat  and  technical  support,  including  a 
dedicated  EMC  test  facility. 

Control  is  exercised  by  two  steering  comnittees,  both  chaired  by  MOD(PE).  The  first  directs  future 
policy  and  considers  recommendations  from  the  main  comnittee  for  new  standards,  working  groups  etc.  The 
second  is  a  specialist  group  concerned  with  the  formulation  of  the  test  methods  to  be  used  within  the  EMC 
facility. 

The  primary  objective  of  the  DTSC  is  to  produce  and  promulgate  defence  standards  for  airborne  data 
transmission  interface  systems.  Other  aspects  of  the  DTSC  terms  of  reference  include: 
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isation  is  continually  reviewing  the  likely  impact  of  new  technology  so  as  to  be  prepared  for  standard¬ 
isation  requirements  and  opportunities  in  future  systems. 

(ii)  Consideration  of  the  applicability  of  existing  national  and  international  standards.  This  is 
an  important  aspect  since  the  adoption,  where  practical,  of  suitable  existing  standards  avoids  dupli¬ 
cation  of  effort  and  enhances  the  possibility  of  NATO  interoperability. 

(iii)  Assessment  of  the  extent  to  which  it  is  possible  to  implement  standards  to  meet  requirements. 
This  aspect  concerns  the  balance  that  any  standards  organisation  must  make  between  applications  that 
appear  regularly  enough  to  benefit  from  standardisation,  as  opposed  to  those  of  a  special  nature  where 
resources  would  not  justify  the  creation  of  new  standards. 

(iv)  Promotion  and  adoption  of  the  standards  nationally  and  internationally.  Having  produced  stan¬ 
dards  it  is  important  to  advertise  their  existence  and  encourage  their  use  so  that  the  full  benefits 
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countries  as  well  as  promoting  its  own  internationally  through  its  formal  liaison  activities. 

(v)  Recommendations  and  provision  of  guidance  in  the  application  of  the  standards.  Standards  are 
by  definition  rather  concise  documents  with  little  guidance  on  interpretation  or  practical  implemen¬ 
tation  aspects.  Jne  ul  the  main  activities  of  c'TSC  has  been  the  production  of  guides  to  help  system 
and  component  designers,  project  managers  etc  understand  and  use  the  standards  correctly. 

As  already  mentioned,  liaison  with  other  national  and  international  standardisation  bodies  is  a  very 
important  aspect-  of  DTSC  activities,  and  either  direct  representation  or  regular  correspondence  is  main¬ 
tained  with  a  number  of  bodies  in  order  to  expedite  the  exchange  of  information.  Some  of  the  bodies 
currently  included  are  USAF,  ASCC  WP  50,  NATOS  MAS  (AVSWP),  SAE  A-2K/AE-9,  DELSC,  BSI,  EUROCAE,  ARINC,  IBA. 

It  was  also  stated  earlier  that  the  DTSC  operates  in  a  number  of  working  groups.  To  date,  four  of 
these  working  groups  have  produced  standards  for  publication  in  the  DEF  STAN  00-18  series,  together  with 
supporting  guidance  information.  The  DEF  STAN  will  now  be  described  before  discussing  the  associated  work¬ 
ing  group  activities. 

3  DEF  STAN  00-18 

All  standards  produced  by  DTSC  have  been  published  as  individual  parts  in  the  DEF  STAN  00-18  series, 
which  has  been  allocated  to  avionic  data  transmission.  This  has  provided  a  compact  format  where  all  the 
standards  are  related  together  using  common  terminology  and  layout.  Part  1  contains  all  the  guides  which 
have  been  written  as  companions  to  the  individual  standards,  which  appear  in  parts  2-5. 

3.1  Multiplex  data  bus  standard 

In  1977,  MIL  STD  '553A  wag  recommended  by  the  then  DISC  as  being  suitable  for  UK  avionic  applications. 
By  the  time  DTSC  was  formed,  firm  national  support  had  been  established  for  adoption  of  the  new  'B'  version 
which  was  under  consideration  in  the  US,  and  in  the  formulation  of  which  RAE  was  involved. 

DTSC  thus  had  a  firm  mandate  to  incorporate  1553B  within  the  00-18  series,  and  the  Multiplex  Data  Bus 
Working  Group  was  set  up  to  progress  it.  The  wording  and  format  of  the  US  document  does  not  conform  with 
the  drafting  rules  laid  down  by  DEF  STAN,  and  it  was  also  considered  neceesery  to  'anglicise'  some  of  the 
phraseology  to  improve  clarity. 

The  work  was  undertaken  to  re-draft  MIL  STD  1553B  into  the  DEF  STAN  format,  and  a  firm  policy  decision 
was  taken  chat  the  two  documente  muet  remain  technically  identical,  to  preserve  compatibility.  The 
Standard  was  published  as  DEF  STAN  00-18  (Part  2)  in  April  1980  .  The  main  differences  from  1553B  are  in 
the  clause  numbering  s,  .'em,  the  use  of  metric  units,  and  some  phraseology.  All  diagrams  are  similar,  but 
the  Appendix  from  1553B,  dealing  with  redundancy,  teiltiplex  selection  criteria  and  reliability  aspects,  has 
been  omitted  from  Part  2  and  included  in  the  Part  1  Guide  (discussed  in  section  3.5). 

The  Working  Group  has  been  responsible  for  preparation  and  maintenance  of  this  section  of  the  Guide, 
and  cucliiatee  to  ej-vrJlrsle  retoOBW.iditivhi  updates.  TTttcugh  it*  liaison  with  iAi  auJ  UEftF  In  pat" 
ticuler,  the  Working  Group  continue*  to  clarify  point*  of  contention  or  interpretation. 

3.2  Single  source,  Single/oultiple  Sink  (SSSMS)  interface  standard 

This  elate  of  interface  can  find  widespread  application  in  simple  systems,  and  vat  identified  by  DISG 
a*  a  ataudardlasclon  objective.  uTSt  concluded  ebat  Whereat  Farr  2  f 1 553b J  could  be  employed  tor  eucn 
applications  there  wee  still  a  case  for  defining  the  simpler  standard,  since  the  overheads  in  the  interface 
circuitry  and  software  for  handling  the  command/retponse  protocols,  which  are  not  required  for  the  SSSMS 
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application,  might  be  a  deterrent  to  its  use.  The  lack  of  a  suitable  simpler  standard  may  then  give  rise 
to  the  type  of  proliferation  which  DTSC  was  trying  to  limit. 

The  SSSMS  Working  Group  was,  therefore,  established  to  define  and  produce  such  a  standard.  Several 
existing  methods  and  systems  were  reviewed,  such  as  the  Panavia  64  kbit/s  system  used  in  Tornado,  ARINC  453 
and  429,  as  well  as  STANAG  4153  and  4156.  All  were  rejected,  however,  in  favour  of  a  system  derived  from 
Part  2  (I553B)  using  its  resilient  electrical  features,  which  would  ensure  good  electromagnetic  compat¬ 
ibility.  Furthermore,  transmitter/ receiver  hardware,  transformers,  bus  couplers  and  cable  were  specified 
to  be  identical  to  those  for  Part  2  (I553B)  systems. 

The  protocol  was  deliberately  kept  simple,  just  enabling  the  transmission  of  data  words  or  data/tag 
word  pairs  where  the  tag  word  can  act  as  an  identifier  or  qualifier,  as  in  ARINC  429  systems. 

Numerous  single-source  requirements  can  be  met  by  this  simple  system,  which  was  published  as  DEF  STAN 
00-18  (Part  3)  in  January  1981.  A  guide  to  the  use  of  the  Standard  is  included  in  Part  1. 

3.3  Discrete  signal  interfaces  standard 

Discretes  have  traditionally  been  considered  to  be  simple,  low  level  interfaces,  not  worthy  of  par¬ 
ticular  attention,  especially  for  standardisation.  Analysis  of  recent  aircraft  systems,  however,  has 
shown  a  substantial  increase  in  the  number  and  types  of  essentially  similar  but  different  discrete  types, 
the  implications  of  which  are  interface  and  electromagnetic  incompatibility,  increased  volume  and  mass  and, 
of  courae,  higher  costs. 

Thus,  the  Discretes  Working  Group  was  established  to  investigate  the  problem  of  reducing  the  prolifer¬ 
ation  to  the  minimum  necessary  aet  which  could  be  incorporated  into  a  standard.  Through  the  work  of  the 
Group,  the  main  functional  requirements  for  discretes  in  avionics  systems  were  isolated,  and  three 
categories  of  discrete  were  identified  as  candidates  for  standardisation.  Within  each  of  these  categories 
a  single  interface  was  then  defined  to  cover  the  majority  of  applications. 

The  three  categories  are  as  follows: 

(a)  Time-critical  signalling 

These  discretes  signal  time-critical  events,  such  as  weapon  release,  audio  blanking,  event  mark¬ 
ing  etc.  The  specified  time-critical  discrete  employs  balanced,  differential  signalling  directly 
coupled  using  the  same  cable  specification  as  Part  2  (1553B)  systems,  thus  ensuring  commonality.  The 
link  itself  can  handle  a  pulse  repetition  frequency  up  to  100  kHz. 

(b)  Non-time-critical  signalling 

Thase  discretes  signal  non-time-critical  conditions,  such  as  status  flags,  mode  indications, 
secondary  alarms  etc.  The  specified  non-time-critical  discrete  employs  single  wire  transmission,  with 
the  aircraft  ground  used  ss  the  signal  return.  The  transmitting  switch  element  can  be  either  electro¬ 
mechanical  or  solid  state,  and  the  receiving  element  is  a  simple  comparator  with  defined  threshold  and 
hysteresis  characteristics. 

(c)  Low  power  switching 

These  discretes  provide  power  with  the  signal  for  driving  lamps,  relays  etc.  The  specified  low 
power  discrete  defines  an  electromechanical  or  solid  state  switch  from  a  load  (lamp  or  relay)  to  the 
aircraft  28  V  supply.  Switching  currents  of  up  to  0.2  A  are  handled,  and  specifications  are  laid  down 
for  such  parameters  as  rise  and  fall  times,  on-state  voltage  drop,  off-state  leakage  and  inductive 
load  protection. 

These  three  discrete  specifications  have  been  incorporated  into  DEF  STAN  00-18  (Part  4)  which  was 
published  in  May  1981.  The  standard  has  been  particularly  successful  at  rationalising  the  large  number  of 
discrete  options,  and  extensive  EMC  testing  has  been  undertsken  both  at  RAE  and  ERA  Technology.  The 
existence  of  the  standard  has  also  encouraged  the  development  of  suitable  monolithic  interface  circuits, 
through  the  careful  choice  of  electrical  and  physical  parameters. 

UK  has  submitted  this  standard  for  consideration  by  both  NATO  and  ASCC. 

3.4  Fibre  optic  transmission  standard 

The  fibre  optic  transmission  standard  proved  to  be  the  most  difficult  to  define,  since  the  pace  of 
technological  change  has  precluded  any  attempt  to  standardise  at  this  time  on  emitter/detector  types, 
modulation  techniques  or  connector  types.  However,  the  production  of  a  standard  was  considered  desirable 
in  order  to  stimulate  and  focus  the  attention  of  industry  on  the  special  problems  encountered  in  the 
avionics  environment. 

Thus  the  Fibre  Optics  Working  Group  was  formed  to  consider  the  best  way  of  approaching  the  standard¬ 
isation  of  optical  data  transmission.  I.  was  decided  that  a  structured  format  would  be  employed  which  was 
capable  of  being  updated  and  expanded  as  the  technology  sutures. 

The  standard  was  published  as  DEF  STAN  00-18  (Part  5)  in  May  1981,  and  comprises  six  sections  dealing 
with  different  aspects,  as  follows: 

(i)  Section  A  provides  an  introduction,  a  definition  of  terms  used  throughout  the  document  and  a 
section  dealing  with  the  purpose  and  limitations  of  the  Standard. 
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(ii)  Section  B  deals  with  general  requirements  such  as  the  test  and  operating  conditions,  optical/ 
electrical  interface  descriptions  and  the  LRU/Harness  considerations.  At  present  three  optical  cable 
diameters  are  specified  (100,  250  and  800  y),  although  this  is  likely  to  be  revised  in  the  near 
future;  in  particular,  250  p  is  likely  to  be  changed  to  200  p. 

(iii)  Section  C  defines  a  1  Mbit/s  single-source  transmission  system  where  the  performance  is 
characterised  in  terms  of  rise/fall  times,  pulse  and  space  widths.  No  constraint  is  placed  on  the 
number  of  sinks. 

(iv)  Section  D  defines  a  10  Mbit/s  single  source  system  which  is  characterised  in  the  same  way  as 
the  I  Mbit/s  system. 

(v)  Section  E  defines  the  general  requirements  for  an  optical  stub  on  the  Part  2  (I553B)  multiplex 
data  bus  and  shows  what  configurations  might  be  used  in  practice. 

(vi)  Section  F  defines  the  use  of  either  the  I  Mbit/s  or  10  Mbit/s  data  systems  for  fibre  optic 
discrete  interfaces,  specifying  the  transmission  rise  times  and  propagation  delay  so  as  to  retain 
compatibility  with  its  electrical  counterparts  of  Part  4. 

Although  the  fibre  optic  standard  requires  further  development,  its  existence  has  stimulated  discussion 
and  comment,  and  it  has  promoted  fibre  optic  technology  development.  Fibre  optics  can  now  be  considered  as 
a  realistic  alternative  to  the  use  of  electrical  transmission  media  for  avionic  systems.  DEF  STAN  00-18 
(Part  5)  is  under  consideration  by  both  NATO  and  ASCC. 

3.5  Guide  to  DEF  STAN  00-18 

The  complex  nature  of  aircraft  data  systems  has  revealed  the  need  for  user  guides  to  the  standards  in 
order  to  assist  project  managers,  equipment  and  component  suppliers,  aircraft  constructors  and  system 
designers. 

The  information  contained  should  present  detail  on  the  background,  scope  and  purpose  of  the  standards 
as  well  as  the  results  of  practical  implementation,  so  it  is  important  that  the  information  is  regularly 
updated  to  include  the  latest  experience. 

This  has  been  recognized  during  the  development  of  DEF  STAN  00-18,  where  the  whole  of  Part  I  has  been 
allocated  to  the  guides  which  are  the  companions  to  the  standards  in  Parts  2-5.  Part  I  is  divided  into  a 
number  of  sections. 

Section  1  is  a  general  introduction  which  is  intended  to  provide  the  user  with  a  rapid  overview  of  the 
choice  of  standards  available  together  with  a  brief  description  of  their  capabilities  and  applications. 
Section  2  is  devoted  to  a  detailed  appraisal  of  the  multiplex  data  bus  standard,  and  includes  material  from 
the  USAF  Multiplex  Handbook  as  well  as  UK  experience.  Of  particular  interest  are  Chapter  3  on  preferred 
remote  terminal  responses  and  Chapter  1 1  on  testing. 

Section  3  provides  a  similar  breakdown  for  the  single  source,  single/multi  sink  data  transmission 
system,  and  Sections  4  and  5  deal  with  the  discrete  and  fibre  optic  standards,  respectively. 

4  OTHER  DTSC  ACTIVITIES 

In  addition  to  the  working  groups  set  up  for  the  development  of  the  standards  detailed  above,  thei e 
has  been,  and  continues  to  be,  working  grouo  activity  in  other  areas.  Some  of  these  are  now  discussed. 

4. 1  Preferred  Components  Working  Group 

This  Group,  which  was  discontinued  in  1981,  was  intended  to  review  the  components  requirements  for 
engineering  any  of  the  standards  in  the  DEF  STAN  00-18  family.  It  concentrated  mainly  on  the  Part  2  (1553B) 
requirements,  looking  at  the  availability  of  transformers,  connectors  and  cables,  and  was  responsible  for 
highlighting,  for  example,  the  need  for  improved  specification  bus  coupling  transformers.  The  Group's 
activities,  however,  were  made  largely  redundant  as  more  and  more  suppliers  offered  components  that  met  the 
required  specifications,  and  the  Group  was  wound  up. 

4.2  Terminal  Testing  Working  Group 

One  major  problem  in  using  the  Part  2  ( . 553B)  standard  was  considered  to  be  the  interpretation  of 
many  of  the  clauses  concerning  the  operation  of  the  coamunications  protocol.  It  was  felt  that  this  could 
result  in  remote  terminal  designers  producing  interfaces  that  were  incompatible  for  certain  functions. 

In  order  to  alleviate  this  problem,  the  Terminal  Testing  Working  Group  was  formed  and  tasked  with  the 
development  of  a  universal  production-type  test  plan,  the  contents  of  which  would  represent  an  agreed  UK 
test  philosophy  and  interpretation  of  the  standard.  This  would  then  assure  a  reasonable  first-order  com¬ 
patibility  between  terminals  designed  and  manufactured  in  the  UK,  and  would  form  the  basis  of  an  agreed 
acceptance  procedure  to  be  used  by  prime  contractors  for  all  Part  2  (I553B)  interfaces  from  whatever  source. 

The  outcome  to  date  has  been  the  first  issue  of  the  test  plan,  incorporated  in  Part  I,  as  discussed  in 
section  3.5  above,  together  with  a  list  of  preferred  terminal  responses  to  cotnands  ttv  t  are  illegal  or 
illogical,  and  which,  as  such,  are  not  specified  in  the  standard. 

4. 3  Video  Working  Group 

This  is  the  newest  of  the  DTSC  working  groups  and  was  established  in  1981  to  consider  the  source,  sink, 
distribution  and  line  standards  for  avionic  video  systems.  It  is  the  first  standardisation  area  to  come 
under  DTSC  consideration  which  is  non-digital  in  nature. 
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To  dace,  most  emphasis  has  been  placed  on  Che  examination  of  line  standards,  and  a  draft  UK  standard 
has  been  developed  which  is  compatible  with  the  recomnendations  of  NATO  STANAG  3350.  This  has  rationalised 
the  large  number  of  available  line  standards  down  to  three,  known  as  Class  A  (875  lines).  Class  B 
■(6M  linwj  wn9  Sltos  "Therec  efiuf  amn  laid  in  ten™  ot  *11  -tJit  wjriW'iAlrkig  its. 

tolerance  and  levels  of  the  baseband  video  waveform.  The  standard  will  be  published  in  the  near  future  as 
DEr  STAN  00-18  (Part  6). 

5  FUTURE  DTSC  ACTIVITIES 

Future  plans  for  DTSC  activities  include  the  continued  support  of  DEF  STAN  00-18,  with  a  periodic 
review  of  the  standards  and  their  guides.  Where  appropriate,  revised  documents  will  be  issued. 

Principally,  however,  near  and  longer  term  standardisation  objectives  will  continue  to  be  formulated 
which  will  take  account  of  advances  in  technology  and  development  of  system  requirements.  Several  new 
areas  are  currently  under  consideration,  as  detailed  below. 

5.1  Video  distribution 

The  use  of  video  in  modern  avionic  systems  is  increasing  as  more  and  more  sources  of  video  from  remote 
sensors  and  waveform  generators  are  required  to  be  interfaced  with  the  display  systems  for  navigation  and 
weapon  aiming.  This  has  highlighted  the  need  to  produce  uniform  requirements  for  such  aspects  as  source 
and  sink  interfaces  and  distribution  characteristics  in  addition  to  the  line  standard  work  mentioned  in 
section  4.3. 

Work  being  undertaken  on  the  definition  of  source  and  sink  interfaces  will  result  in  electrical 
specification  for  both  balanced  and  unbalanced  systems,  in  terms  of  impedances,  voltage  levels,  rise  times 
and  circuit  protection  requirements,  together  with  the  definition  of  such  transmission  characteristics  as 
bandwidth,  crosstalk,  signal/noise  ratio  and  gain. 

The  resulting  standard  will,  thus,  include  all  aspects  of  the  video  system  from  generation  to  display. 
Longer  term  objectives  will  include  a  review  of  colour  and  digitally  encoded  video  requirements. 

5.2  Fibre  optics  multiplexing 

Fibre  optic  technology  already  plays,  an  important  role  in  aircraft  data  transmission  because  of  its 
superior  EMC  and  isolation  characteristics  and  the  resulting  potential  wide  bandwidth.  The  achievement  of 
DEF  STAN  00-18  (Part  5)  has  already  been  discussed,  but  the  only  multiplex  application  so  far  addressed 
has  been  the  development  of  fibre  optic  stubbing  techniques  for  electrical  busses. 

A  near  term  objective  will  be  the  replacement  of  the  complete  electrical  bus  with  a  fibre  optic 
solution,  and  DTSC  has  been  in  contact  with  SAE  A2-K  (AE9-C)  on  the  potential  MIL  STD  1773.  Further  into 
the  future,  fibre  optics  is  a  strong  candidate  as  the  medium  for  video  distribution  and  will  probably  be 
essential  for  any  form  of  high  speed  bus  application. 

5.3  High  speed  multiplex  bus 

Future  generation  avionic  systems  will  embody  processing  capability  far  in  excess  of  current  systems 
through  the  use  of  new  technologies  such  as  VLSI.  There  will  almost  certainly  be  a  requirement  for  a  high 
speed  data-passing  bus,  probably  in  excess  of  20  Mbit/s. 

The  development  of  such  systems  is  still  in  the  research  phase,  and  DTSC  has  not  considered  the  field 
'oe  v i-ndacAi -w.1 «  '  ir (f  isrt its, '  a  r«r«av'  ewtliTg  tritf  is  ^  £t,l  r  i'*<  ^  Arms  ,r 
in  UK  and  elsewhere,  and  it  is  hoped  to  co-operate  in  the  work  of  the  High  Speed  Bus  Sub-committee  (AE9-B) 
of  SAE  in  USA. 

5.4  Multiplex  data  buB  word  standardisation 

As  MIL  STD  1553B  and  equivalent  data  busses  are  finding  widesparead  application  throughout  the  aero¬ 
space  industry,  a  natural  leaning  is  towards  the  standardisation  of  word  and  message  formats  transmitted 
on  the  bus.  This  can  improve  compatibility  between  transmitting  and  receiving  subsystems  as  well  as 
allowing  form,  fit  and  function  (F^)  objectives  to  be  met. 

Currently,  the  major  activity  in  this  area  has  been  concentrated  in  a  task  group  of  the  SAE  AE9-A 
Committee,  from  which  recommendations  are  emerging.  DTSC  is  contributing  to  this  exercise  through  the 
auspices  of  the  NATO  MAS  AVSWP,  and  a  UK  version  will  probsbly  be  drafted  as  an  advisory  part  of  the 
DEF  STAN  00-18  (Part  1)  guide. 

6  CONCLUSIONS 

During  the  four  years  of  its  existence,  DTSC  has  demonstrated  the  major  benefits  of  a  co-ordinated 
national  effort  towards  the  standardisation  of  aircraft  data  transmission  systems.  The  value  of  joint 
Government  and  Industry  participation  has  been  immense,  as  both  parties,  manufacturer  and  customer  alike, 
have  co-operated  in  the  development  of  standards.  This  has  resulted  in  their  insediate  acceptance  when 
required  for  use. 

Four  published  and  one  draft  standard  have  so  far  been  produced  which,  together  with  the  guides, 
represent  s  significant  investment  in  time  and  effort.  The  result  is  a  mature,  compatible  family  of 
standards  backed  up  by  a  large  test  and  evaluation  programme.  This  provides  the  UK  with  a  good  capability 
for  our  own  aircraft  system  designs,  together  with  the  necessary  experience  to  participate  fully  in  the 
various  international  standardisation  activities. 

Copyright,  ©,  Controller,  HUSO  London,  1981 
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SUMMARY. 

-si«h  ile  studying  the  design  of  Total  Aircraft  Systems  using  MIL-STD-15J3  Data  Buses 
the  need  for  interbus  communication  protocols  in  multibus  architectures  was  established. 
Two  types  of  interbus  communication  were  identified  as  necessary^  Cyclic  message 
transfers  and  Acyclic  message  transfers.  Cyclic  messages  are  handled  by  assigning 
specific  subaddresses  in  the  Bus  Controller  Remote  Terminals  which  receive  and  pass  on 
these  messages  to  the  appropriate  destination  on  a  cyclic  basis  as  preprogrammed  in  the 
relevant  Bus  Controllers.  Acyclic  messages  are  handled  by  a  special  protocol  based  on 
the  use  of  the  Service  Request  Bit  in  the  status  word,  the  Transmit  Vector  Word  Mode 
Code,  a  specially  formulated  Vector  Word,  special  Data  Words  which  are  used  as  Interbus 
Transmit  and  Interbus  Receive  Command  Words,  together  with  the  use  of  reserved 
subaddresses,  one  for  each  bus  on  the  network.  This  protocol  is  explained  in  detail 
together  with  the  measures  taken  in  the  Subsystem  to  Remote  Terminal  Interface  to  ensure 
orderly  transmission  of  data  and  effective  error  recovery  with  lost  or  corrupt  messages. 


1.  INTRODUCTION. 

British  Aerospace  Brough  has  been  working  on  the  design  of  Total  Aircraft  Systems 
using  MIL-STD-1553  Data  buses  for  some  four  years.  During  the  last  two  years  this  effort 
has  largely  been^concentrated  on  the  design  and  construction  of  an  Avionic  Systems 
Demonstrator  Rig  (A.S.D.R.)  funded  by  the  Ministry  of  Defence. 

The  number  of  devices  which  have  to  be  attached  to  the  data  bus  in  an  aircraft 
system  with  distributed  processing  forces  the  adoption  of  a  multibus  architecture. 

(fig. 5) 

MIL-STD-1553  does  not  provide  any  explicit  features  for  the  handling  of  interbus 
message  transfers.  A  problem  which  had  to  be  solved  for  this  multibus  system  was  the 
specification  of  a  set  of  techniques  and  protocols  which  allowed  a  range  of  interbus 
message  transfers  based  on  the  MIL-STD-1553  building  bricks. 

These  protocols  had  to  cope  with  a  number  of  possible  Bus  Network  configurations. 

i.  A  star  configuration  where  one  bus  is  a  master  and  all  the  other  buses  are 
attached  directly  to  this  bus.  (fig.l) 

ii.  A  chain  configuration  where  the  buses  form  a  linear  network,  (fig. 2) 

iii.  Combinations  of  i.  and  ii.  effectively  giving  a  tree  configuration. 

(fig. 3) 

A  general  requirement  was  made  that  the  techniques  and  protocols  devised  should  be 
able  to  cope  with  any  of  these  types  of  bus  network. 

The  architecture  designed  for  the  A.S.D.R.  is  a  three  bus  system  comprising  an 
Avionics  Bus,  a  General  Services  or  Utilities  Bu?  and  a  Stores  Management  Bus.  These 
buses  are  interconnected  by  having  Remote  Terminals  at  the  back  of  the  General  Services 
and  Stores  Management  Bus  Controllers  attached  to  the  Avionics  Bus.  See  fig.  (4). 

The  message  types  which  had  to  be  provided  for  the  A.S.D.R.  were 

Bus  Controller  to  Remote  Terminal  and  Remote  Tt  .  nal  to  Bus  Controller  where 

the  Bus  Controller  and  Remote  Terminal  were  on  arate  buses. 

Remote  Terminal  to  Remote  Terminal  where  the  two  Remote  Terminals  were  on 

separate  buses. 

All  these  types  of  message  transfer  had  to  be  organised  for  both  Cyclic  and  Acyclic 
transfers.  It  was  considered  unnecceSary  to  have  Interbus  Broadcast  messages  and  so 
explicit  protocols  for  this  were  not  devised  although  the  acyclic  protocols  would  permit 
this  type  of  transfer. 

2.  CYCLIC  DATA  TRANSFER. 

Cyclic  messages  are  the  simplest  to  organise  and  can  be  done  in  two  possible  ways 
dependent  on  the  number  of  messages  that  need  to  use  this  technique.  If  the  number  of 
messages  to  be  transferred  is  small  (less  than  20)  then  a  separate  si.baddress  can  be 
assigned  to  each  message  and  the  relevant  Bus  Controllers  programmed  to  transfer  the 
messages  to  and  from  the  correct  sources  and  destinations  at  the  desired  rates. 

For  example s- 

If  it  is  required  to  send  a  message  of  10  data  words  from  the  Fuel  Management  System 
subaddress  6  on  the  General  Services  Bus  to  the  Display  System  subaddress  3  on  the 
Avionics  Bus  the  following  sequence  of  events  must  take  place. 
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A  general  requirement  was  made  that  the  techniques  and  protocols  devised  should  be 
able  to  cope  with  any  of  these  types  of  bus  network. 

The  architecture  designed  for  the  A.S.D.R.  is  a  three  bus  system  comprising  an 
Avionics  Bus,  a  General  Services  or  Utilities  Bus  and  a  Stores  Management  Bus.  These 
buses  are  interconnected  by  having  Remote  Terminals  at  the  back  of  the  General  Services 
and  Stores  Management  Bus  Controllers  attached  to  the  Avionics  Bus.  See  fig.  (4). 
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Remote  Terminal  to  Remote  Terminal  where  the  two  Remote  Terminals  were  on 
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transfers.  It  was  considered  unnecceSary  to  have  Interbus  Broadcast  messages  and  so 
explicit  protocols  for  this  were  not  devised  although  the  acyclic  protocols  would  permit 
this  type  of  transfer. 

2.  CYCLIC  DATA  TRANSFER. 

Cyclic  messages  are  the  simplest  to  organise  and  can  be  done  in  two  possible  ways 
dependent  on  the  number  of  messages  that  need  to  use  this  technique.  If  the  number  of 
messages  to  be  transferred  is  small  (less  than  20)  then  a  separate  subaddress  can  be 
assigned  to  each  message  and  the  relevant  Bus  Controllers  programmed  to  transfer  the 
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For  example 

If  it  is  required  to  send  a  message  of  10  data  words  from  the  Fuel  Management  System 
subaddress  6  on  the  General  Services  Bus  to  the  Display  System  subaddress  3  on  the 
Avionics  Bus  the  following  sequence  of  events  must  take  place. 
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The  General  Services  Bus  Controller  as  part  of  its  normal  cyclic  message  transfer 
sequence  sends  the  command  word  to  the  Fuel  Management  System  to  transmit  10  data  words 
from  subaddress  6.  The  General  Services  Bus  Controller  receives  these  data  words  and 
transfers  them  into  subaddress  15  of  its  Remote  Terminal  on  the  Avionics  Bus.  (We  have 
arbitrarily  chosen  subaddress  15  for  this  specific  message) .  At  subaddress  15  these  data 
words  overwrite  the  previous  contents  thus  ensuring  that  the  data  is  always  fresh.  The 
Avionic  Bus  Controller  as  part  of  its  cyclic  message  transfer  sequence  sends  the 
commandwords  to  the  Display  System  to  receive  10  data  words  at  subaddress  3  and  to  the 
General  Services  Bus  Controller  Remote  Terminal  to  transmit  10  data  words  from 
■jubsddrias  1^  data  wof<^  eft  a,,J  <■  prcctfie  La 

complete.  Because  these  messages  are  cyclic  error  recovery  is  simplified,  either  the 
normal  repeats  of  messages  upon  error  detection  by  the  relevant  bus  controllers  ensures 
that  the  message  gets  through,  or  we  accept  that  a  new  message  is  following  in  a  few 
aillibvSunJl.  ifr.f  fe'-^efy  bey***!  this  strW'tgf  1#  fexbple*  ■SwvJ  La  tj 

the  Executive  Function  of  the  Bus  Controller,  the  discussion  of  which  is  outside  the 
scope  of  this  paper. 

If  the  number  of  messages  to  be  transfered  is  large  then  we  can  adopt  the  same 

general  strategy  but  we  now  make  the  first  data  word  in  each  package  a  header  word  which 

uniquely  identifies  the  package  of  data. 

The  messages  are  transferred  as  before  but  now  we  can  send  several  different 

messages  to  the  same  subaddress,  the  receiving  system  decodes  the  header  word  and  copies 

the  rest  of  the  message  out  of  the  subaddress  it  was  received  at  into  a  safe  area  within 
the  subsystem. 

When  using  this  header  technique  in  order  to  prevent  overwriting  of  messages  within 
the  Bus  Controller  subaddresses  we  must  queue  the  transfers  from  receive  subaddress  to 
transmit  subaddress  and  force  the  communicating  buses  to  run  in  synchronism  on  a  minor 
cyclic  basis  so  that  the  queues  are  emptied  every  minor  cycle.  Error  recovery  becomes 
more  difficult  because  only  a  very  limited  amount  of  time  can  be  allocated  to  retries  if 
the  buses  are  not  to  get  too  far  out  of  sync  so  that  the  queues  fill  up  and  messages  are 
lost. 


3.  ACYCLIC  DATA  TRANSFER. 

The  technique  devised  for  the  transfer  of  acyclic  messages  is  most  easily  explained 
by  going  through  examples. 

Let  us  suppose  that  the  Display  System  (RT  12)  on  the  Avionics  Bus  needs  to  receive 
at  subaddress  16  a  package  of  10  words  of  acyclic  diagnostic  data  from  the  Fuel 
Management  System  (RT  7)  on  the  General  Services  Bus.  This  package  is  available  at 
subaddress  12  of  the  Fuel  Management  System  and  so  the  Display  System  formulates  two 
special  data  words.  One  is  an  Interbus  Transmit  Word  which  is  used  to  form  the  Command 
Word  on  the  General  Services  Bus  to  cause  the  Fuel  Management  Unit  to  transmit  10  data 
words  from  subaddress  12.  The  other  is  an  Interbus  Receive  Word  which  is  used  to  form 
the  Command  Word  on  the  Avionics  Bus  to  cause  the  Display  System  to  receive  10  data 
words  at  subaddress  16. 


The  Interbus  Transmit  Word  is  made  up  as  follows  :- 
bits  0-4 


The  codes  are 


bits  5-9 

bit  10 
bits  11  -15 


contain  a  special  Executive  code  to  identify  the  bus  to 
which  the  data  is  to  return. 

11100  -  for  the  General  Services  Bus 

11110  -  for  the  Stores  Management  Bus 

11111  -  for  the  Avionics  Bus 

contain  the  subaddress  from  which  the  data  is  to  be 
transmitted. 

is  always  set  to  a  one. 

contain  the  Remote  Terminal  address  from  which  the  data  is 
to  originate. 


so  for  this  example  it  will  be  :- 

0011110110011111 


3  D  9  F 


Hex 
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The  Interbus  Receive  Word  is  made  up  as  follows  :- 

bits  0-4  contain  the  word  count  field.  This  specifies  the  number  of 

actual  data  words  to  be  sent. 

bits  5-9  contain  the  subaddress  field  at  which  the  data  is  to  be 

received  in  the  requesting  subsystem. 

bit  10  is  always  set  to  a  zero. 

bits  11  -  15  contain  the  Remote  Terminal  address  at  which  the  data  is  to 

be  received. 


so  for  this  example  it  will  be  :- 

0110001000001010 
6  2  0  A  Hex 


These  two  words  are  placed  in  subaddress  29  by  the  Displays  System  and  then  a 
special  Vector  Word  is  created  which  is  formatted  as  follows:- 

bits  0-4  contain  the  Word  Count  of  the  desired  message.  (That  is 

two;  the  Interbus  Transmit  and  Receive  Words). 

bits  5-9  contain  the  subaddress  of  the  Remote  Terminal  with  which 

communication  is  desired.  If  communication  is  desired  with 
the  Executive  Function  of  the  Bus  Controller  or  with  a 
Remote  Terminal  on  another  bus  then  this  field  contains  a 
code  word  to  be  interpreted  by  the  Executive  Function,  (see 
bits  11  -  15.) 

bit  10  indicates  whether  the  Remote  Terminal  specified  by  the  RT 

address  field  bits  11  -  15  should  transmit  or  receive,  a 
one  indicating  transmit. 

bits  11  -  15  contain  the  Remote  Terminal  address  field  with  which 

communication  is  desired.  If  this  field  is  set  to  all  zeros 
then  the  desired  communication  is  interpreted  as  a  special 
code  for  the  Executive.  A  Remote  Terminal  address  field  of 
all  ones  is  interpreted  as  a  request  to  broadcast. 

The  relevant  special  Executive  codes  are  as  follows: 

11100  indicates  that  the  Remote  Terminal  generating  the  Vector 

Word  would  like  to  communicate  with  a  Remote  Terminal  on 
the  General  Services  Bus. 

11110  indicates  that  the  Remote  Terminal  generating  the  Vector 
Word  would  like  to  communicate  with  a  Remote  Terminal  on 
the  Stores  Management  Bus. 

11111  indicates  that  the  Remote  Terminal  generating  the  Vector 
Word  would  Like  to  communicate  with  a  Remote  Terminal  on 
the  Avionics  Bus. 

and  so  will  be  for  this  example  :- 

0000001110000010 
0382  Hex 

This  Vector  Word  is  loaded  into  the  Remote  Terminal  and  then  the  Service  Request  bit 
is  set  in  the  Status  Word. 

The  Bus  Controller  detects  the  Service  Request  and  sends  a  Transmit  Vector  Word  Mode 
Code  to  the  Displays.  The  Displays  System  responds  with  the  Vector  Word  and  is  decoded 
by  the  Bus  Controller  which  then  requests  the  Displays  to  transmit  two  data  words  from 
subaddress  29  (the  Interbus  Transmit  and  Receive  Words).  The  Avionics  Bus  Controller 
remembering  the  request  in  the  Vector  Word  for  interbus  communication  with  the  General 
Services  Bus  causes  these  two  data  words  to  be  received  by  the  Avionics  Bus  Remote 
Terminal  on  the  General  Services  Bus  Controller  (RT  11)  at  subaddress  24. 
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Four  subaddresses  are  reserved  in  each  bus  controller  for  interbus  acyclic 
communications :- 


SA 

24 

is 

for 

the 

General  Services  Bus 

SA 

25 

is 

for 

the 

moment  spare 

SA 

26 

is 

for 

the 

Stores  Management  Bus 

SA 

27 

is 

for 

the 

Avionics  Bus 

Because  the  two  data  words  were  sent  to  subaddress  24  then  the  General  Services  Bus 
Controller  interprets  the  words  as  intended  for  it  and  decodes  the  first  data  word  (the 

Interbus  Transmit  Word).  Since  bit  10  is  a  one  it  knows  that  this  is  an  Interbus 

Transmit  Word  and  decodes  it  as  follows:- 

The  field  of  bits  0  -  4  is  saved  by  the  General  Services  Bus  Controller  remembering 
that  it  decodes  to  the  Avionics  Bus.  The  field  of  bits  0  -  4  in  the  second  data  word 

(Interbus  Receive  Word)  is  then  copied  into  the  field  of  bits  0  -  4  in  the  Interbus 

Transmit  Word.  The  Interbus  Transmit  Word  is  then  sent  on  the  general  services  bus  as  a 
command  word  to  the  Fuel  Management  Unit  to  transmit  10  data  words  from  subaddress  12. 

These  data  words  are  received  by  the  General  Services  Bus  Controller  which  adds  them 
to  the  Interbus  Receive  Word  to  make  a  package  of  11  data  words  which  it  makes  available 
at  subaddress  29  it  then  sets  up  a  Vector  Word  to  request  the  Avionics  Bus  Controller,  to 
receive  11  data  words  (Interous  Receive  Word  4  10  data  words) . 


This  Vector  Word  is  made  up  as  follows  :- 


bits  0-4 
bits  5-9 

bit  10 
bits  11-15 
So  we  have:- 


01011  the  word  count  (11). 

11111  indicates  a  transfer  to  the  Avionics  Bus  saved  from 
bits  0  -  4  of  the  Interbus  Transmit  Word. 

0  indicates  receive. 

00000  indicates  a  special  executive  code. 

0000001111101011 

0  3  E  B  Hex 


The  General  Services  Bus  Controller  Remote  Terminal  then  sets  its  Service  Request 
bit  in  the  Status  Word. 


The  Avionic  Bus  Controller  sees  the  Service  Request  bit  set  and  requests  a  Victor 
Word  which  when  decoded  asks  it  to  receive  11  data  words  from  the  General  Services  Bus 
Controller  Remote  Terminal  subaddress  29  (  subaddress  29  is  used  by  convention  with 
Vector  Words) . 

The  Avionics  Bus  Controller  receives  these  data  words  which  it  knows  from  the  Vector 
Word  are  a  message  for  the  Avionics  Bus.  It  decodes  bit  10  of  the  first  data  word  and 
because  it  is  a  zero  knows  that  this  is  an  Interbus  Receive  Word. 

It  then  sends  the  whole  package  onto  the  Avionics  Bus  using  the  Interbus  Receive 

Word  as  a  Command  Word  and  the  following  words  as  the  10  data  words. 

The  Display  system  receives  these  10  data  words  at  subaddress  16  and  the  transaction 
is  completed. 

The  above  example  describes  a  request  to  transmit  form  of  transaction.  If  we  had 
organised  the  data  transfer  from  the  other  end  then  we  would  have  had  a  request  to 
receive  transfer  which  would  have  been  set  up  as  follows. 

The  Fuel  Management  System  on  the  General  Services  Bus  formulates  one  special  data 
word  the  Interbus  Receive  Word  whic..  it  places  in  subaddress  29  followed  by  the  ten  data 
words.  A  Vector  Word  to  request  to  send  eleven  data  words  to  the  Avionics  Bus  is  created 
and  placed  in  the  Remote  Terminal  Vector  Word  Register  and  the  Service  Request  bit  is 
then  set. 

The  Interbus  Receive  Word  would  be:-  6  2  0  A  Hex 

The  Vector  Word  would  be:-  0  3  E  B  Hex 

The  General  Services  Bus  Controller  detects  the  Service  Request  and  asks  the  Fuel 
Management  Unit  to  transmit  its  Vector  Word.  This  is  decoded  and  the  Fuel  Management 
Unit  is  then  asked  to  transmit  eleven  data  words  from  subaddress  29.  The  General 
Services  Bus  Controller  knowing  that  this  is  a  message  for  the  Avionics  Bus  from  the 
Vector  Word  places  these  data  words  in  subaddress  29  of  its  Remote  Terminal  on  the 
Avionics  Bus.  It  then  sets  up  a  Vector  Word  to  send  eleven  data  words  to  the  Avionics 
Bus  Controller  and  sets  its  Service  Request  Bit. 
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The  Vector  Word  would  be:-  0  3  E  B  Hex 

The  Avionics  Bus  Controller  detects  the  Service  Request  and  asks  the  General 
Services  Bus  Controller  Remote  Terminal  to  transmit  its  Vector  word.  This  is  decoded  and 
ft*  tiwowral  SertUiK  Una  Co'U.rtilljis  n  Tprralral  Is  rhen  a.iM?  to  team  emit 

data  words  from  subaddress  29.  The  Avionics  Bus  Controller  knowing  that  this  is  a 
message  for  the  Avionics  Bus  from  the  Vector  Word  decodes  the  first  data  word.  Because 
bit  10  is  a  zero  it  knows  that  this  is  an  Interbus  Receive  Word  and  decodes  the  rest  of 
the  wet  d  Etewt  dingis .  Tr.it  a.no-u-nlt  it  using  this  wol  d  w.  a  Con&and  Wuid  -on  the  7a  i<  v.iiT 
Bus  to  send  the  other  ten  data  words  to  the  Displays  System  at  subaddress  16.  The 
Displays  System  receives  this  data  and  the  transaction  is  complete. 

The  examples  given  above  are  only  two  of  a  large  range  of  acyclic  interbus 
curaBur.icati^ri9,  l!»3  ical'af  shtuis  be  aLlu  to  dwt i»<s  the  pcfta-ilAb  data  iranttjrr 

from  the  component  parts  of  these  examples. 

With  certain  bus  configurations  it  is  possible  to  arrange  shorter  total  transfer 
paths  than  given  by  these  general  techniques.  In  practice  however  the  generality  of 
these  techniques  is  a  very  significant  advantage,  it  is  possible  to  add  extra  data 

transfers  to  a  bus  network  without  making  any  changes  to  the  Bus  Controllers,  whereas  a 

less  general  technique  would  not  permit  this. 

4.  SUBSYSTEM  INTERFACE  PROTOCOL. 

tx>  «*'.  1/  •ytuthjr om iaai  icjt  protlmt  iryi'i  hr  muni  only  w  teyclir  m 

be  active  per  subsystem  at  a  time.  In  interbus  transfers  once  it  has  left  the  original 

bus  then  it  is  permissible  to  activate  a  further  Acyclic  message  since  the  return  path 

is  a  separate  transaction. 

In  order  to  retain  synchronism  it  is  necessary  to  adhere  to  a  strict  protocol  when 
transmitting  Vector  Words  and  receiving  or  transmitting  the  associated  data.  Two  flags 
are  used  to  control  the  process,  the  acyclic  sent  flag  and  the  acyclic  busy  flag. 

When  a  subsystem  requires  to  transmit  data  the  data  and  its  associated  Vector  Word 
are  placed  on  a  queue  in  the  subsystem  interface  storage  area. 

The  subsystem  interface  software  monitors  the  acyclic  busy  flag  and  if  this  is  not 
set  it  then  tests  this  queue  and  if  it  detects  an  entry  it  decodes  the  Vector  Word  and 
processes  it  accordingly. 

If  the  Vector  Word  describes  a  request  to  send  data  to  another  Remote  Terminal  or  a 
special  interbus  transaction  then  the  data  word/words  are  unqueued  and  placed  in 
subaddress  29  transmit,  the  Vector  Word  is  unqueued  and  placed  in  the  Vector  Word 
Register,  the  acyclic  sent  flag  is  set,  the  acyclic  busy  flag  is  set  and  the  Service 
Request  Latch  is  set  in  the  subsystem  interface. 

Tht  ivsxt  Cyclic  transaction  frjm  the  i.eHu>le  Terminal  will  have  the  Etrviet  ..eqaest 
bit  set  in  its  Status  Word. 

The  Bus  Controller  upon  recognising  the  Service  Request  will  set  up  a  Transmit 
Vector  Word  request  to  the  Remote  Terminal,  the  Remote  Terminal  transmits  the  Vector 
Mbvd  and  *  Ltaj  i  i  •  w  fwqwm-s  Utfh  i'  l**  ituflies,  ««evvi  m 

decodes  the  Vector  word  and  sets  up  the  data  transfer .  The  subsystem  by  definition  sends 

the  data  from  subaddress  29  and  when  this  occurs  the  Remote  Terminal  clears  the  acyclic 
sent  flag. 

The  subsystem  interface  software  must  periodically  (not  more  frequently  than  10ms  or 
less  frequently  than  200ms)  test  the  acyclic  busy  flag  and  if  it  is  set  then  it  checks 
the  acyclic  sent  flag,  if  it  is  clear  then  the  acyclic  busy  flag  should  be  cleared  and 
that  iteration  of  the  subsystem  interface  software  exited.  Any  time  that  the  subsystem 
interface  software  is  called  and  the  acyclic  busy  flag  is  clear  then  the  acyclic  queue 
should  be  checked  to  see  if  there  are  any  entries.  If  transactions  are  found  on  the 
queue  they  are  then  processed  as  discussed  above. 

This  technique  ensures  that  the  retry  scheme  of  repeat  twice  on  original  bus  then 
repeat  twice  on  alternate  bus  has  sufficient  time  to  run  to  completion  if  necessary 

before  the  subaddress  data  is  overwritten  by  the  following  transaction  in  the  event  of 

there  being  one  on  the  queue. 

Timers  must  be  maintained  on  the  control  flags  and  if  a  flag  having  been  set  is 
not  cleared  within  300ms  then  the  flags  should  be  cleared  and  that  particular 
transaction  requeued.  If  a  transaction  is  requeued  4  times  without  succeeding  then  it 
should  be  abandoned  to  avoid  clogging  up  the  bus  and  some  suitable  recovery  action 
taken. 

The  actual  techniques  used  on  the  A.S.D.R.  are  more  complex  than  the  above 
description  since  there  are  other  types  of  acyclic  message  using  the  queue  than  the 
interbus  transactions  described. 


5.  CONCLUSION. 


These  Cyclic  and  Acyclic  Interbus  Data  Transfer  techniques  have  been  implemented  on 
the  B.Ae.  Brough  A.S.D.R.  and  are  currently  being  used  successfully  in  a  complex  data 
transfer  environment.  This  environment  includes  message  sequence  tables  which  change 
with  phase  of  flight,  dynamically  changed  sequence  tables  to  cope  with  failures  in 
redundant  systems,  dual  bus  controllers  with  dynamic  handover  if  one  fails  and  broadcast 
message  transfers. 

Work  is  continuing  on  the  expansion  of  the  A.S.D.R.  and  many  other  features  of  data 
buses  remain  to  be  assessed  in  the  coming  months. 

6.  REFERENCES. 

MIL-STD-1553B  Aircraft  Internal  Time  Division  Command  Response  Multiplex  Data 

Bus. 
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DISCUSSION 


M.A.J.Burfoid,  UK 

Previous  speakers  have  voiced  the  opinion  that  multi-layered  buses  may  cause  unacceptable  time  delays  in  the 
system.  Certainly  the  use  of  a  “common”  terminal  to  provide  a  post  box  between  the  two  buses  would  appear  to 
have  the  effect  of  a  lag  built  into  the  system.  Have  you  managed  to  establish  the  maximum  rate  of  irutfbus  data 
flow  and  if  so  what  is  it?  If  the  interbus  data  flow  is  to  be  minimised,  have  the  bus  functionalities  beer,  optimised  in 
order  to  ensure  this  and  if  so  could  you  please  outline  the  methodology  used  to  validate  the  choice  of  bus  functions. 

Author’s  Reply 

We  have  not  established  a  maximum  rate  of  interbus  data  bus  flow.  Because  of  the  data  latency  problems  it  is 
desirable  to  minimise  interbus  traffic  rates  as  far  as  possible.  Other  considerations,  however,  (mainly  bus  integrity 
levels)  prevent  choosing  the  systems  on  the  various  buses  to  minimise  interbus  traffic.  If  data  latency  is  a  serious 
problem  then  there  is  perhaps  a  need  for  dedicated  links  between  the  affected  systems.  Bus  latency  is  however  only 
a  part  of  the  problem,  asynchronous  operation  of  processors  and  I/O  buffering  can  have  effects  just  as  great  if  not 
greater.  I  believe  that  this  needs  to  be  addressed  as  a  total  system  problem  for  each  case.  The  acyclic  interims 
protocols  described  in  the  paper  are  intended  to  be  used  for  signals  which  are  transmitted  only  a  few  times  per  flight 
and  the  latency  associated  with  the  technique  is  not  a  problem.  The  latency  of  the  cyclic  technique  is  a  function  of 
the  minor  cycle  rates  on  the  intercommunicating  buses-,  in  general  cases  it  averages  at  about  twice  the  single  bus 
latency. 
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A  VIDEO  BUS  FOR  WEAPON  SYSTEM  INTEGRATION 


Dr.  P.  L.  Currier/W.  E.  Miles 
General  Dynamics  Corporation 
Fort  Worth,  Texas,  76101, USA 


imROOUCTIOM 

The  total  costs  associated  with  retrofitting  an  existing  aircraft  to  integrate  a  new  weapon  are 
staggering.  At  the  airframe  manufacturer  there  are  the  costs  of  scheduling, engineering,  drafting  .developing 
shop  plans,  purchasing,  receiving,  kitting,  storing,  opening  aircraft  wings,  installing,  testing, 
qualifying,  inspecting,  ferrying,  changing  training  manuals,  training  ground  crews  and  defining  logistical 
needs.  The  Air  Force  has  additional  direct  costs  of  scheduling,  planning  for  reduced  fleet  strength  during 

retrofit,  and  training  ground  crews.  And  there  are  still  other  costs  in  defining  the  new  weapons  to  be 

integrated,  modifying  the  affected  weapon  delivery  software,  simulating,  flight  testing  and  crew  training. 
To  add  a  pair  of  new  control  wires  to  an  existing  aircraft  could  easily  generate  non-recurring  costs  of 
millions  of  dollars! 

MIL- STD- 1760  is  a  far-sighted  approach  to  eliminate  most  of  these  costs  and  to  reduce  many  of  the 
others .  The  standard  defines  the  mechanical  and  electrical  characteristics  of  the  connector  interface  for 
new  weapons.  As  a  joint  Air  Force/Navy  standard,  all  new  weapons  will  be  required  to  be  designed  such  that 

all  command,  control ,  and  communication  with  those  stores  will  occur  through  these  pre- defined  connector 

pins .  Once  an  aircraft  is  built  to  meet  the  connector  requirements ,  then  any  new  weapon  can  be  added  by  only 
changing  the  weapon  delivery  software.  The  purpose  of  this  paper  is  to  highlight  the  problems  an  airframe 
manufacturer  faces  in  adopting  the  standard,  ami  to  focus  on  the  solution  of  one  of  these  problems,  viz,  the 
video  requirements  of  the  standard. 


MIL- STD-1760  SUMMARY 

The  goal  of  MIL-STO-1760  is  to  define  for  all  tines  the  electrical  interface  for  new  stores.  All  the 
electrical  cabling  needs,  computer  interfaces,  and  weapon  system  architecture  can  be  built  into  a  new 
aircraft  today,  and  they  will  not  need  significant  (or  any)  changes  for  the  foreseeable  future.  The  airfrasw 
manufacturer  has  strong  impetus  to  meet  the  standard  at  whatever  costs  today,  to  be  in  a  position  to  readily 
accomodate  the  needs  of  his  customers  in  the  future.  Stores  developers  have  the  seam  impetus  since  their 
products  can  now  be  integrated  into  all  new  aircraft  in  a  straight  forward  fashion.  Figure  1  shows  the 
locations  where  a  -1760  connector  is  likely  to  exist  on  the  airframe.  The  -1760  connector  can  reside  at 
either  the  wing  hardpoint,  or  within  a  rack.  The  standard  attempted  to  provide  a  mix  of  interface  types 
sufficient  for  all  power,  command,  control  and  communication  with  a  store.  Figure  2  and  the  accompanying 
table  show  the  connector  pin  arrangement  and  the  signal  types.  It  is  seen  thet  power,  serial  digital  and 
discrete  signal  types  have  been  provided. 


OR 


FIGURE  1.  I11L-STD-1760  CONNECTOR  LOCATIONS 
TO  SERVICE  A  STORE 


Copyright  C  1983  by  General  Dynamics  Corporation,  All  Rights  Reserved. 
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WOMEWCLATURE  CONTACT  LOCATION 


FIBER  OPTICS  BUS  A 
115V  AC  RETURN 
RELEASE  CONSENT 
HIGH  BANDWIDTH  A 
HIGH  BANDWIDTH  3 
ADDRESS  BIT  Aj 
HIGH  BAf'UWIDTH  1 
ADDRESS  RETURN 


ADDRESS  BIT  A. 


FIGURE  2.  M1L-STD-1760  CONNECTOR 
PIN  ASSIGNMENTS 


CONTACT  LOCATION  NQMIM1M 
A  AUDIO 

B  INTERLOCK 

C  28V  DC  POWER  1 

D  POWER  1  RETURN 

E  POWER  2  RETURN 

F  28 V  DC  POWER  2 

G  ADDRESS  PARITY 

H  MUX  BUS  B 

J  115V  AC.0C 

K  MUX  BUS  A 

L  ADDRESS  BIT  Ag 

M  115V  AC.0B 

N  270V  DC  RETURN 

P  115V  AC.CA 

R  270V  DC  POWER 

S  INTERLOCK  RETURN 

T  STRUCTURE  GROUND 

U  FIBER  OPTICS  BUS  B 

V  ADDRESS  BIT  A^ 

W  HIGH  BANDWIDTH  2 

X  ADDRESS  BIT  Aj 


In  spit*  of  *11  tb*s«  positiv*  features  and  benefits ,  wirfraan  Manufacturers  are  not  st tabling  over 
tbeeselves  to  universally  incorporate  the  standard.  Fighters  and  fighter /bcabers  reflect  a  compromise  of 
drag,  lift,  fuel  and  avionics.  If  an  aircraft  is  to  have  a  reasonable  nvaber  of  store  stations  and  all  of 
then  are  to  be  compatible  with  -1760,  than  a  rather  large  channel  must  be  created  for  the  cabling;  an  area 
that  otherwise  could  have  been  used  for  fuel.  Is  it  reasonable,  the  airfrsner  nay  ask  hinself,  to  expect  a 
store  on  a  wing  tip  that  would  require  30  firn  and  two  RF  lines?  Figure  3  conveys  the  Magnitude  of  the 
problem  for  a  generic  aircraft  with  a  reasonable  mafcer  of  weapon  stations.  Perhaps  it  is  More  reasonable  to 
designate  certain  weapon  stations  for  air-to-air,  others  for  air-to-ground,  some  for  pods  and  e  fsw  general 
purpose. 


FIGURE  J.  MULTIPLE  STORES  STATIONS  FOR 
LARGE  SURFACE  AREA  AIRCRAFT 


An  Air  Force  study  (VIM  program,  AFAL/AAAT)  predicted  a  future  aircraft  with  as  aaoy  as  SO  weapon 
Nrdpointe .  A  fully  compatible  -1760  connector  at  all  those  locations  would  constitute  a  very  siseable  cable 
harness .  It  would  be  easy  to  adopt  a  weapons  loading  philosophy  of  dedicated  stations  for  this  sort  of 
vehicle,  providing  power,  video,  V,  and  MXL-S1D-1SS3 ,  only  where  it  is  likely  to  be  needed.  Unfortunately, 
the  history  of  technology  development  has  on*  clear  lesson— very  few  people  are  able  to  forecast  the  future 
with  any  accuracy,  and  no  one  can  predict  who  those  people  are.  To  rule  out  the  possibility  of  * 
wingtip- noun  ted  store  in  the  1990  'e  that  would  retire  30  anperes,  -1SS3,  video  and  V  would  be  shear  folly. 
(The  staple  fact  that  store  dasipters  can  asstas  those  interfaces  are  available,  alnoet  assures  that  someone 
will  design  something  to  us*  them,  |  After  losing  an  arpaant  with  himself  the  airframer  has  only  on* 
ietalligent  answer.  Meet  the  standard. 
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What  the  airframer  suet  then  do  i>  reduce  the  problem  to  one  of  identifying  a  top-level  integration 
philosophy  that  will  meet  the  anticipated  future  need*.  Given  that  everything  ie  necessary ,  the  system 
designer  needs  to  define  bow  it  will  all  be  managed.  The  questions  become:  who, is  in  charge;  how  will  the 
«A1«  ranting  occur;  if  additional  electronic  element*  are  necessary,  bow  will  built-in  test  octw .  how  can 
the  network  integrety  be  evaluated  ; where  does  fault  recording  occur;  and  so  on.  These  questions  are  answered 
within  the  physical  limits  of  the  airframe.  For  example,  the  designer  may  limit  the  stores  loading  in  total 
power  consumption,  number  of  active  RP  lines,  etc.  Even  when  this  approach  is  followed,  there  are  some 
especially  difficult  pfjoleM.  General  DynNaicS  is  dedicated  to  providing  full  compliance  to  -ITTv  at  every 
station,  but  the  implications  of  some  of  the  requirements  are  difficult  at  best.  One  of  these  is  the  two 
signal  interfaces  in  the  standard  called  "high  bandwidth  3(4,  video". 


-1760  VIDEO  REQUIRBOJTS 

The  standard  Him  the  (iJe.  requirement*  ia  leal  than  tar  pagf  .  Usctr L-eally  Lbt  tin  rtda t  pir» 
are  to  be  bi-directional  ports  with  20  M4s  bandwidth  and  a  characteristic  impedance  of  75  ohms.  The  channels 
are  to  be  a  high  quality  conduit  for  525  line  video  in  RS-170  format  or  875-line  video  in  RS-343  format. 
There  are  no  other  uses  defined  for  these  pins,  but  they  are  open  for  any  signal  falling  within  a  20  HTz 
bandwidth.  Iaplied  in  the  dual,  bi-directional  aspect  of  the  standard  is  the  provision  for  cotasunication 
between  stores .  It  is  easy  to  anticipate  a  store  with  a  requirement  for  correlating  video  from  several 

weapon  stations  in  order  to,  say,  slew  a  video,  seeker  bead  in  a  weapon  fr-Ji  a  pattern  recognizer  in  another 
pod.  Looking  to  the  future,  the  system  designer  can  visualize  a  need  for  full  bi-directionality  in  the 
weapon  station  video,  as  well  as  simultaneously  displaying  it  in  the  cockpit.  What  this  describes  is  a 
sizeable  network  within  the  aircraft  to  achieve  this  need.  For  a  vehicle  with  the  number  of  stations 
described  in  the  VI DS  study,  it  is  a  potentially  very  complex  network.  This  network  becomes  even  more 
complicated  when  one  recalls  that  the  extremes  of  temperature,  shock  and  vibration  are  experienced  in  the 
wing*  VW  fuiUrna  is  a  1’sr-aij.u-f  J  al  u « Mali  sms  to  sms'  Us  mIJbw  -wads 


VIDEO  DISTRIBUTION  SYSTEM  ALTERNATIVES 


Electro-mr.ehaiu.cal  Switching  Matrix 

There  are  numerous  ways  to  meet  the  requirements  of  the  standard  while  Meting  the  needs  of  the 
vehicle.  There  is  no  one  right  approach  for  all  aircraft,  rather  different  answers  for  different 
circumstances.  The  simplest  network  is  one  composed  of  electro-mechanical  relays.  This  method  requires 
coaxial  cables  to  run  from  weapon  stations  to  a  central  switching  matrix  that  acta  like  a  telephone  operator 
affecting  the  required  connections.  This  type  network  becomes  unique  to  the  host,  aircraft.  The  size  and 
complexity  of  the  switch  is  determined  by  the  maber  of  stations,  the  maximum  r.uaber  of  simultaneous 

communications  desired,  and  the  maximum  nuaber  of  sinka  required  for  any  source  (i.e.,  is  it  to  be  a  simple 

point-to-point  network,  or  are  multiple  destinations  desired:  station- to- station- to- cockpit? ).  Figure  4 

show  a  simplified  version  of  a  switch  allowing  two  simultaneous  paths  and  only  one  destination.  When 
mechanized  in  an  aircraft  a  simple  switch  can  be  centrally  located,  or  a  distributed  network  can  be 

constructed  with  local  matrices.  For  example  each  wing  could  have  a  matrix  that  ia  tied  to  a  fuselage 

matrix. 


CONTROL 


CONTROL 


FIGURE  <t.  ELECTRO-MECHANICAL  SWITCHING  MATRIX 
ELEMENTS.  SHOWS  HOW  A  VIDEO  LINE  CAN  BE  COUPLED 
TO  ANY  OTHER  VIDEO  LINE  USING  RELAYS 
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The  aajor  advantages  to  this  approach  ar^  low  coat,  aultipla  vendor* ,  and  tha  twitching  center*  can 
ha  built  without  power  auppliaa— tha  relay*  deriving  their  excitation  froa  the  controlling  aource.  Control 
over  tha  relay*  could  ccew  froa  the  weapon  atation  interface  unit*  in  tha  atorea  aanageaant  aet ,  auch  that 
tha  atorea  coaputar  would  activate  the  connection. 

There  are  aany  weaknesses  in  auch  a  network.  Relay*  are  not  a  favored  technology.  They  tend  to  wear 
out  eaaily  and  their  durability  i*  adversely  affected  by  vibration.  The  maber  of  relay*  required  to 
construct  a  fully  inter-connectable  aatrix  that  ia  capable  of  several  simultaneous  channels  grows  in  a 
g* nitric  proportion.  This  approach  does  not  expand  eaaily  either,  to  add  another  station  causes  a  redesign 
of  the  aatrix.  A  final  issue  i*  the  aixed  bl easing  of  a  passive  aatrix  without  a  power  supply.  The 
controlling  sources  must  have  discrete  power  driver*  with  all  the  associated  filtering  to  protect  the  naster 
unit. 

Solid  State  Switch 

Many  of  the  objections!  aspects  of  aacbanical  relays  could  be  reaoved  by  constructing  the  aatrix  with 
solid  state  relays .  Semiconductor  technology  certainly  has  the  potential  for  better  reliability  than  a 
aechanical  system.  The  power  requiresanta  of  the  controlling  signals  could  be  reduced  (probably  via  a 
multiplex  bus),  and  the  coats  could  be  influenced  by  silicon  econoay  of  scale.  Unfortunately,  this 
alternative  trades  one  set  of  probleas  for  another.  The  standard  calls  for  20  HHz  channel  bandwidth — a  range 
not  currently  accomodated  in  any  coaqponent,  to  the  best  of  our  knowledge.  The  network  is  to  be 
bi-directional,  iapiying  a  rather  sophisticated  circuit  Module  to  prevent  feedback.  And  finally  the  aatrix 
would  become  a  powered  unit  requiring  built-in  testa,  self-test  and  a  fault  isolation/reporting  function. 
Figure  5  is  a  graphic  representation  of  the  functional  elesanta  required  in  a  solid  state  switch. 


SWITCH  SENSE  BUFFER 
AMP  AMP 


FIGURE  5.  CIRCUIT  ELEMENTS  IN  A  BIDIRECTIONAL  SOLID  STATE 
SWITCH  TO  PREVENT  FEEDBACK 


Fiber-optic  Network 


A  technology  with  features  that  should  lend  thewelvsa  nicely  to  video  distribution  is  fiber  optics. 
Optical  fibers  are  all  dielectric,  bene*  i wanna  to  electromagnetic  effects.  Even  in  a  high  electrical  noise 
environment  the  fibers  themselves  will  contribute  nothing  to  corrupt  the  signals  being  carried  within  thee. 
The  fibers  are  physically  small  and  can  be  cabled  such  that  many  separate  signal  path*  are  contained  within  a 
snail  1  disaster,  very  flexible  cable.  A  network  can  be  visualised  that  employs  optical  fibers  and  a  solid 
state  switching  approach.  Figure  6  is  a  presentation  of  a  distributed  network  with  local  switching  and 
multiplexing  in  the  wing  and  a  central  interconnect  in  the  fuselage.  Optical  fiber  bundles  interconnect  the 
aatrix  elesanta. 


BUNDLE  OF 


TO  HARD  POINTS 


FIGURE  6.  DISTRIBUTED  FIBER-OPTIC  NETWORK 
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This  network  is  subject  to  the  sase  drawbacks  as  the  wire  version  discussed  above,  plus  the  added 
cost  of  a  transmitter/ receiver  pair  at  each  end  of  the  optical  fibers  (together  with  a  store  complicated  fault 
isolation  requireaent ) .  The  benefits  that  are  added  are  noise  immunity  and  physically  ssialler  interconnects 
between  matrix  nodules.  (The  entire  subjects  of  field  naintainence  and  environmental  effects  on  fiber-optic 
connectors  will  be  ignored  in  this  paper. )  Where  optical  fibers  begin  to  make  sense  is  when  the  network 
described  above  can  be  converted  to  a  totally  passive  distribution  system.  That  is,  converting  the 
electro-optical  switching  eleswnts  into  optically  passive  elesients.  If  it  were  possible  to  switch  or 
distribute  the  light  from  the  originating  fiber  to  the  proper  destination  without  going  through 
optical-to-electrical  then  electrical-to-optical  conversions,  a  considerable  cost  and  complexity  savings 
could  be  realized. 

Several  methods  of  achieving  light-in,  light-out  networks  have  been  developed,  and  they  have  varying 
degrees  of  success  for  small  networks .  Figure  7  is  a  schematic  presentation  of  two  passive  networks .  The 

star  coupler  in  figure  7a  will  take  the  incoming  light  from  one  fiber  and  uniformly  distribute  it  among  all 

the  fibers  attached  to  the  coupler.  This  technique  has  been  demonstrated  for  several  years  in  the  form  shown 
in  the  figure,  and  in  a  form  that  has  separate  transmit  and  receive  fibers.  The  point  to  notice  in  this 
scheme  is  that  the  sum  of  the  exiting  optical  power  is  equal  to  the  input  power  minus  any  insertion  losses. 
Thus  a  perfect  16-port  coupler  will  create  12  dB  optical  power  attenuation.  Typically  the  connector  at  the 

coupler  will  contribute  another  1-2  dB  and  the  internal  mechanises  arc  not  perfect,  so  a  realistic  16-port 

coupler  might  have  a  total  insertion  loss  of  20  to  24  dB.  This  power  loss  cannot  be  made  up  by  increasing 
the  optical  source  power  in  practical  systems.  Thus  the  network  has  a  finite  (and  small)  amount  of  optical 
power  that  will  be  considerably  attenuated  before  it  is  received  by  a  noise-limited  detector  (typically  a  PIN 
photodiode).  Preserving  an  adequate  signal -to- noise  ratio  essentially  limits  the  number  of  terminals  on  the 
network.  The  bandwidth  of  the  detector  preamplifier  establishes  a  noise  floor,  the  optical  source  (ideally 
an  LED,  rather  than  a  more  expensive  laser  diode)  establishes  the  amount  of  optical  power  in  the  network,  and 
the  passive  network's  attenuation  will  combine  to  determine  the  final  signal -to- noise  ratio. 

Frequency  multiplexing  techniques  to  achieve  simultaneous  channels  one  must  be  challenged  immediately 
because  the  increased  bandwidth  raises  the  noise  floor  in  the  detectors .  A  different  multiplexing  technique 
that  is  being  pursued  in  earnest  in  the  fiber-optics  industry,  however,  is  "color"  multiplexing.  Optical 
sources — LED's  and  laser  diodes — can  be  made  very  narrow  band,  and  by  using  semiconductor  doping  techniques 
the  frequency  ("color")  of  the  emitted  light  can  be  shifted  adequately  so  that  several  "shades"  of  infrared 
can  be  transmitted  in  the  same  fibers  without  significant  interference.  Most  detectors  are  silicon  based, 
hence  rather  broadband,  permitting  the  same  detector  to  receive  any  of  the  shades  and  filter  techniques  have 
been  developed  to  permit  a  detector  to  the  unique  shades . 

Once  developed,  color  multiplexing  will  be  useful  for  many  systems.  Right  now  the  color  selection  in  the 
transmitter  is  a  semiconductor  process ,  so  a  network  designer  would  need  to  be  clever  to  avoid  conditions 
where  transmitters  of  the  same  color  need  to  coamunicate  at  the  sane  time. 

Figure  7b  is  a  bi-conical  tee.  This  is  the  fiber-optic  version  of  a  weighted  power  splitter.  A 
small  portion  of  the  power  in  the  network  is  routed  off  to  a  detector  with  the  remainder  continuing  along  the 
■hi a  highway.  The  main  advantage  in  this  approach  over  star  couplers  is  that,  the  optical  octopus  of  the 
previous  example  can  be  avoided,  reducing  the  amount  of  cabling.  All  the  limitations  of  the  previous  scheme 
still  apply— insertion  losses,  bandwidth  restrictions,  source  power,  etc. 


(*) 


FIGURE  7.  PASSIVE  OPTICAL  COUPLERS 

(l)  REFLECTIVE  (»)  SI-CONICAL  TEE 


Digitised  Video 

Digital  techniques  are  frequently  used  for  distribution  and  manipulation  of  analog  signals  because 
once  digitised,  the  signal  is  unaffected  by  corrupting  effects  of  traditional  electrical  noise  sources.  To 
preserve  a  20  Mis  channel,  the  Nyquist  criteria  says  at  least  a  40  Mix  sampling  ia  required.  Assuming  that 
one  could  reconstruct  the  original  waveform  on  the  fly  when  sampled  at  this  rats,  and  also  assiadng  that  tan 
bits  of  digitising  resolution  is  adequate  to  recreate  a  smooth  picture  (60  A)  ,  than  a  400  IGits/sec  channel 
would  be  required.  A  data  compaction  technique  could  obviously  reduce  tbs  bandwidth;  indeed,  dramatic 
compression  has  been  achieved  for  video  imagery.  Figure  8  depicts  tbs  central  elements  in  such  a  scheme. 


18-6 


TRUNK 


VIDEO 


FIGURE  8.  ELEMENTS  IN  A  DIGITAL  VIDEO  NETWORK 


Thi*  approach  becomes  Bessy  when  simultaneous  coa«uni cations  are  required.  The  actual  network  bit 
rate  could  be  increased  to  permit  tiae  division  multiplexing  on  a  coaaon  bus,  or  Multiple  paths  could  be 
employed  driving  the  design  into  a  solid  state  switch/ digital  network  analogous  to  our  second  exaaple. 
Whenever  the  bit  rates  begin  to  exceed  30  (Cits /sec  the  distribution  path  takes  on  additional  complexity 
since  transmission  line  effects  will  becoae  serious  problems .  And  finally  there  is  some  question  as  to  the 
exact  nature  of  bandwidth  compression  that  can  be  tolerated  in  a  weapon  sensor  video  system.  A  compression 
technique  that  works  fine  for  htatans  looking  at  pastoral  scenes  may  be  worthless  when  trying  to  locate  a 
partially  hidden  tank. 

Video  Bus 

The  technique  that  appears  to  hold  the  highest  promise  for  wide  application  is  the  video  bus.  Figure 
9  shows  an  overview  of  this  approach.  Conceptually  this  is  a  single  video  highway  on  which  video  channels 
are  frequency  multiplexed,  much  the  saaw  as  cable  television.  And  in  fact,  this  method  is  realizable  today 
because  of  the  progress  that  baa  been  made  in  the  cable  television  industry  in  miniaturization  and 
ruggedness. 


BUS 


FIGURE  9.  VIDEO  BUS  NETWORK  ARCHITECTURE 


VIDCO  BUS  CHARACTERISTICS 

The  basic  philosophy  behind  a  video  bus  is  that  it  is  possible  to  allocate  frequency  channels  on  a 
coaxial  bus  and  construct  transmitters  and  receivers  capable  of  operating  over  those  channels  without 
interfering  vith  each  other.  Figure  10  indicates  conceptually  bow  the  channelization  would  work.  Carrier 
frequencies  are  established  for  a  mmber  of  channels.  These  carriers  are  selected  in  the  spectrum  such  that 
a  20  Mil  band  about  them  will  not  have  significant  overlap  into  the  adjacent  channel ,  thereby  creating  a 
guard-band  region  between  the  channels.  The  total  mmber  of  channels  is  determined  by  the  mmber  of 
anticipated  simultaneous  required,  plus  some  spares.  Tbs  actual  frequency  range  over  which  the  network  works 
is  a  function  the  components  available  to  do  the  job  and  will  be  transparent  to  the  system  user.  In  fact,  it 
dees  not  matter  that  the  channels  be  equally  spared  or  contiguous;  it  only  matters  that  the  network  elements 
are  easily  able  to  transmit  and  receive  over  thorn. 
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FIGURE  10.  ELECTRO-MAGNETIC  SPECTRUM  SUBDIVISION  FOR  VIDEO  BUS 


The  key  hardware  eleaents  in  this  network  are  modems,  couplers,  a  cable  trunk  line,  digital  coemand 
and  control,  and  locally  multiplexed  video  input  and  output.  Figure  11  depicts  these  elements  in  a 
simplified  terminal.  The  modem  contains  a  transmitter  that  will  modulate  baseband  20  I4iz  signals  at 
predetermined  carrier  frequencies;  and  a  receiver  that  will  perform  the  reverse  operation.  Included  in  this 
circuitry  is  sufficient  filtering,  prescaling  and  signal  conditioning  to  preserve  a  useful  signal-to-noise 
ratio  and  eliminate  corruption  by  other  channels.  The  coupler  connecting  the  modem  to  the  bus  has  two 

features  essential  to  making  the  network  work.  It  must  be  a  passive  device  thereby  not  creating  modulation 
products ,  and  it  must  address  power  ratios ,  so  that  it  only  draws  off  the  amount  of  power  required  by  that 
terminal.  The  cable  trunk  line, the  bus  itself,  is  a  terminated  transmission  line  of  either  coaxial  or 

triaxial  cable.  The  only  essential  constraint  on  it  is  assuring  that  it  remains  a  balanced  transmission  line. 
For  example,  techniques  of  impedance  matching  are  needed  for  the  coupler  attachments  to  preserve  waveform 
quality.  The  modems  need  to  be  controlled  by  a  digital  network  so  that  several  things  will  be  possible. 
First,  of  course,  is  tuning  the  transmitter  and  receiver  in  a  modem.  This  operation  should  require  a  simple 
channel  selection  code  from  the  host  system  and  the  command  and  control  network  would  take  care  of  actually 
setting  the  proper  frequencies.  In  this  way  the  host  system  would  only  need  to  know  that  there  exists  some 
number  of  channels  and  that  they  have  a  unique  identification.  The  host  would  not  know  or  care  anything 
about  what  the  channel  assignments  mean  to  the  modem  electronics;  in  exactly  the  same  way  most  home 
television  viewers  change  channels .  The  digital  system  should  also  cosnand  and  monitor  built-in  tests  over 
the  modem  and  report  the  results  to  the  host.  Vh-ap- around  tests  on  the  transmitter/receiver,  as  well  as 

monitoring  key  functions  are  possible  to  determine  the  health  of  the  hardware.  Self- test  over  the  entire 

network  would  likely  involve  a  human  viewing  a  display. 
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FIGURE  11.  CENTRAL  ELEMENTS  IN  A  VIDEO  BUS  TERMINAL 


Ws  have  asstawd  this  hardware  will  reside  within  another  clamant  in  the  aircraft  and  that  element 
will  have  a  KIL- STD-1553  interface,  thus  total  network  control  will  be  via  a  -1553  system.  To  require  a 
separate  -1553  bus  to  control  the  video  bus  is  undesirable  in  tarns  of  c^xle  and  electronics,  and  is 
redundant  in  a  stores  management  set.  A  small  addition  to  the  video  input/output  circuitry  that  greatly 
enhances  the  operational  features  of  this  approach  is  a  four- to- one  multiplexer.  This  feature  permits  up  to 
four  sources  or  sinks  to  use  each  modem.  In  the  case  of  a  stores  management  set  it  is  common  to  find  a 
weapon  station  with  several  different  attachment  points .  These  are  required  to  be  able  to  physically  carry 
different  store  types  at  a  given  station.  Normally ,  only  one  of  the  hardpoints  is  in  use  at  a  station  at  one 
time,  thus  a  four- to- one  multiplexer  permits  a  single  modem  to  service  tbi  lot.  Finally  a  word  ^out 
software.  In  order  to  simplify  the  flexibility  of  this  approach  as  a  building  block,  there  is  no  resident 
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processing  requiring  software .  The  coaaana  and  control  circuitry  My  contain  a  Micro-sequencer,  but  its 
firmware  is  not  likely  to  change  in  a  mature  system.  This  entire  concept  bus  actually  been  Made  possible  by 
advances  in  the  cable  television  Market.  The  manufacturers  of  video  electronics  have  Made  dramatic  progress 
in  LSI  of  video  processors.  One  need  only  look  at  a  schematic  of  the  latest  television  monitors  to  realize 
that  what  used  to  take  a  jungle  of  components  is  now  done  in  a  single  integrated  circuit.  But  beyond  the 
integration,  the  ccamercial  parts  designers  have  had  their  eye  on  other  goals  as  well.  It  would  not  make 
good  economic  sense  to  design  a  chip  that  would  only  handle  the  52S  line  encoding  of  the  United  States  when 
the  same  circuit  could  possibly  be  designed  to  meet  the  needs  of  Europe,  Brazil  and  others.  So  the  off  the 
shelf  circuitry  for  conventional  home  television  in  some  cases  actually  has  considerably  more  bandwidth  than 
needed.  More  importantly,  it  is  designed  with  processes  that  can  be  pushed  to  accommodate  the  20  Mb: 
required  by  the  standard.  Secondly,  as  a  chip  manufacturer  the  feature  that  will  enhance  a  product  when 
there  are  several  competitors  with  similar  electrical  specifications  is  reliability.  The  cable  television 
market  has  a  self-imposed  standard  that  is  nearly  as  rigorous  as  the  military  surket.  And  again,  in 
achieving  their  own  goals,  the  designers  of  those  circuits  used  processes  that  are  amendable  to  MIL- STB 
processing.  Tn  sUi,  a  video  bus  is  possible  because  of  the  cable  television  industry. 


IM’LEMSNTATION  IN  AN  AIRCRAFT 

It  is  visualised  that  the  video  bus  would  become  a  sub  element  of  a  stores  management  system  (SMS). 
Figure  12  depicts  a  stylized  multibus  avionics  architecture.  This  particular  arrangement  uses  two  -1553 
buses  to  control  and  coordinate  the  avionics  suite  and  a  third  -1553  bus  to  control  the  SMS.  The  SMS  would 
consist  of  a  central  computer  directing  operations  and  store  interface  units  (SIU)  to  coomunicate  with  and 
release  stores.  The  SIU  would  contain  all  the  required  electronics  to  provide  a  -1760  interface,  as  well  as 
tim  discretes  fee  {me- i stores.  The  videv  l»«m  feiecuomes  would  reside  within  the  510 ,  and  a  coaxial  bos 
would  run  parallel  to  the  SMS  -1553  bus.  Commands  to  the  video  bus  modems  that  would  cause  them  to  change 
channels,  perform  wrap-around  tests,  or  reverse  from  a  transmitter  to  a  receiver  would  be  issued  by  the  SMS 
computer  via  its  -1553  interface  to  the  SIU's.  The  SIU  would  translate  these  instructions  as  it  does  for  any 
other  function  in  the  system. 


FIGURE  12.  MULTI-BUS  AVIONICS  ARCHITECTURE 


A  portion  of  the  operational  flight  program  for  the  SMS  computer  would  contain  the  -1760 
characteristics  for  each  store  type.  Another  portion  would  contain  the  logic  to  interconnect  the  -1760 
stores  carried  at  any  time  into  a  useable  configuration.  For  example  this  logic,  once  info  read  of  the  store* 
complement  on  the  vehicle,  would  assign  video  channels  for  video  weapons  or  E-0  pods;  would  attach  to  the 
avionics  hue  those  stores  requiring  -1553  coummication;  would  interconnect  those  pods  with  RF  link 
connections;  and  so  on.  In  operation  the  pilot  could  carry  to  the  vehicle  e  vwaocy  device  containing  mission 
plan,  communication  data,  threat  location*  and  store*  data.  The  mission  computer  would  the  data  to 
initialise  the  system  without  further  pilot  interaction.  Once  airborne  the  pilot  could  call  video  from 
any  store  station  from  a  pictorial  menu  of  options  existing  on  his  plena  at  anv  tins,  displayed  on  hie 
multipurpose  display* .  The  actual  channel  aasignasnts  would  be  transparent  to  the  pilot.  Figure  13  depicts 
the  sequence  in  the  video  hook-up. 
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FIGURE  13.  AUTOMATIC  OPERATION  OF  VIDEO  SELECTION 


An  air-to-ground  node  ii  (elected  and  the  system  automatically  steps  through  a  sequence  that  among 
other  things  routes  video  fro*  an  appropriate  weapon  to  a  display.  That  sequence  within  the  SMS  computer 
mould  inventory  the  available  channels,  command  an  assignment,  run  BIT,  confirm  the  channel  is  good;  then 
latch  up  the  connection.  If  the  channel  should  be  noisy  for  whatever  reasons,  it  is  visualized  that  a 
"reassignment"  switch  could  always  be  part  to  a  multipurpose  display  format.  When  the  pilot  presses  this 
switch  the  SMS  computer  automatically  would  repeat  the  channel  selection  process  and  delete  the  failing 
channel  from  the  list  of  available  choices . 
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.  i  SitMARY  AND  STATUS 

'«>  *  ft  I  ¥'  I  r, 

What  has  been  described  is  a  generic  video  bus  concept  that  is  realizable  within  the  current  state  of 
the  technology.  A  video  bus  can  be  achieved  with  a  smell  set  of  components ,  probably  in  a  pair  of  hybrid 
packages.  Such  a  system  could  be  built  in  a  fundamental  building  block,  applicable  to  any  new  aircraft 
design  (as  well  as  virtually  any  network  requiring  multi-channel  video).  The  growth  of  coaamrcial  cable 
television  has  made  miniaturization  possible,  although  there  is  still  some  development  required  to  meet  the 
-1760  2CM&  requirement  and  a  full  military  temperature  range. 
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PDue  to  the  postulated  1990 's  threat  environment  advanced  avionics  architectures  are  experiencing 
demands  for  increased  performance  which  have  led,  in  part,  to  increased  processing  requirements  and 
system  complexity.  As  more  processors  are  added  to  the  control  environment  of  sophisticated  military 
aircraft,  the  choice  of  processor  interconnection  topology  and  methodology  assumes  greater  Importance. 
This  choice  profoundly  Influences  Information  throughput,  reliability,  survivability  and  integrity 
throughout  the  weapon  system.  The  ability  to  rapidly  exchange/transfer  Information  among  processors 
and  devices  is  critical  if  one  is  to  develop  a  reliable,  effective ^communication  system. 

This  papar  addresses  basic  communication  techniques  which  could  serve  as  candidates  in  satisfying  the 
network  communication  requirements  of  an  advanced  avionics  architecture.  Features  of  each  technique 
are  examined  to  ascertain  the  performance  of  these  multi-access  protocols  in  terms  of  developed  sys- 
tsm-driven  criteria.  4^ 

1.  Integrated  Avionics  System;  An  avionics  system  is  an  assemblage  of  elements  which  perform  a 
particular  set  of  weapon  system  related  functions  (e.g.,  navigation,  weapon  delivery,  flight  control, 
etc.).  Presently,  each  of  these  functions  is  performed  by  autonomous  subsystems  consisting  of  various 
combinations  of  similar  and  standardized  elements  (processors,  sensors,  etc.).  With  few  numbers  of 
these  large  basically  independent  subsystems,  the  interconnection  has  been  accomplished  through  the  use 
of  1  megabit  multiplex  data  buses  (1SS3B).  However,  since  many  of  these  subsystems  consist  of  common 
elements,  it  seems  reasonable  that  a  lower  level  connectivity  philosophy  could  result  in  a  more  reli¬ 
able,  and  efficient  system  design. 

This  new  system  design  would  represent  a  mors  highly  integrated  and  cooperative  avionics  system  with 
the  attendant  advantages  of  reduced  weight,  volume  and  power  consumption  through  the  multifunctional 
use  of  system  elements.  This  multifunctional  use  provides  numerous  benefits:  (1)  a  single  set  of 
sensors  can  be  used  to  satisfy  different  requirements;  (2)  sharing  of  processing  resources  to  satisfy 
diverse  processing  requirements;  and,  (3)  increasing  fault  tolerance  through  system  resource  allo¬ 
cation.  These  benefits,  however,  come  at  an  increased  cost  to  the  communication  systam.  New  require¬ 
ments  are  now  placed  on  the  communication  network— high  bandwidth,  many  data  sources,  sinks,  demand  for 
Increased  reliability. 

Thess  naw  architectural  and  functional  concepts  require  the  communication  system  to  now  handle  internal 
subsystem  deta  traffic  heretofore  transparent  at  the  system  level.  For  example,  the  high-bandwidth 
traffic  between  the  inertial  instruments  and  the  navlgetlon  computer  is  not  visible  beyond  that  subsys¬ 
tem.  In  a  fully  integrated  system,  each  of  the  inertial  Instruments  is  a  shared  resource,  and  the  data 
traffic  between  them  and  the  various  traditional  functions  (navigation,  autopilot  and  fire-control)  and 
advanced  avionics  system  functions  (TF/TA/OA)  must  be  supported. 

It  is  clear  that  when  a  highly  integrated  avionics  system  is  compared  to  more  conventional  dssigns,  the 
numbers  of  comnuniceting  date  terminals  heve  increased  greatly.  Thus,  the  communication  system  is 
deeling  with  a  multiplexing  problem  made  more  complex  by  an  increased  number  of  data  sources  and  sinks. 

Finally,  the  integrated  evionic  system  demands  a  more  reliable  communication  system.  Previous  combat 
elrcreft  weapon  systems  employed  autonomous  subsystems,  sach  of  which  minimized  the  flight-safety 
implicetlon  of  subsystem-to-subsystem  communication  failures.  While  some  data  was  exchenged,  which 
ellowad  subsystems  to  optimize  their  performance,  degraded  modes  and  contingency  control  within  the 
subsystem  provided  safe  control  eltarnatives,  even  if  inter-subsystems  communicet ion  were  to  fail.  In 
effect,  from  e  redundancy  management  perspective,  the  integration  of  the  avlonlce  system  ellows 
significant  reduction  in  tha  number  of  sensors,  displeys,  processors,  etc.,  but  at  the  expenss  of 
incrsesed  connectivity  and  reliability  requirements  for  the  data  communication  system. 

2,  Limitations  of  Current  Deta  Bust  The  existing  bus  stendard  is  MIL-STD-1553B.  This  standard  is  the 
recognised  1  MBIT  Commend /Response  Multiplex  Standard  which  hes  evolved  over  the  past  10  ysars  and 
represente  the  first  eignif leant  stap  towerds  more  integreted  system  deeigns. 

Though  MIL-STD-1553B  will  continue  to  be  used  in  the  yeers  to  come,  the  more  highly  integrated  eystem 
designs  of  tha  futura  as  wall  ae  current  evionic  system  deslgne  hava  identified  erchitectural  limita¬ 
tions  caused  by  ths  stenderd.  Tha  stenderd  doae  not  solve  the  genarlc  problem  of  multlpla  high  rata 
users  in  the  network.  To  circumvent  this  problam  in  presant  aircraft,  the  syetem  deeignare  have 
employed  composite  systems  of  hierarchiel  bus  structures  each  operating  per  1553B  and  dedicetad  wiring. 
However,  hiererchlel  bus  topologies  suffer  transport  delay  whan  data  muet  ba  communicated  between 
busas.  Scheduling  and  coordination  of  deta  trenefar  betwean  busee  in  command  reeponse  eyeteme  becomes 
a  problem  in  thet  software  in  many  dsvicee  muet  be  synchronously  controlled  which  further  degradee 
raal-tlma  performance. 

Whet  must  be  developed,  is  e  data  bus  cepeble  of  hendling  the  erchltacturel  probleme  which  currently 
exist  as  well  es  thoee  of  futuristic  evionics  networks.  It  hee  baen  suggasted  that  the  naxt  ganeratlon 
bussing  stendard  be  tailored  to  eetlsfy  e  specific  type  of  eppllcetlon.  The  bussing  epproach  opti¬ 
misation  would  revolve  around  e  proposed  non-command/control  bursty  trefflc  environment  Involving  mass 
date  exchangas  between  for  example,  stored  alectronic  terreln  maps,  etored  threat  data,  stored  thraet 


data,  stored  mission  plan  programs  and  the  required  processors  to  support  new  functions  such  as  terrain 
maskings  for  improved  low  level  penetration  survivability.  It  is  the  intent  of  this  paper  to  analyze 
various  protocols  from  a  total  systems  point  of  view;  if  it  can  be  shown  that  a  single  bussing  approach 
can  ba  appliad  across  many  applications,  albeit,  sub-optlmally  but  adequately  on  an  individual 
case-by-case  basis,  then  the  more  generic  bussing  approach  should  prevail.  The  data  as  to  the  final 
position  on  this  issue  has  not  been  fully  compiled,  however,  in  anticipation  of  support  of  a  generic 
capability  the  following  analysis  provides  preliminary  insight  to  potential  candidates. 

3.  Selection  Criteria:  Before  a  data  bus  protocol  capable  of  supporting  the  avionics  architectural 
needs  can  be  chosen,  system  driven  criteria  must  be  identified.  The  following  have  been  identified  as 
important  criteria  which  a  data  bus  protocol  analysis  must  address; 

-  Throughput/Response 

-  Effective  Link  Level  Data  Throughput 

-  Data  Latency 

-  Message  Structure  ^ 

-  Addressing  Capacity 

-  Broadcast  Capability 

-  Data  Block  Size 

-  Content  Addressability 

-  System  Integrity 

-  Monitorable 

-  Testable 

-  Ease  of  Initialization 

-  Data  Link  Assurance  of  Receipt 

-  Fault  Tolerance 

-  Feult  Detection 

-  Feult  Containment 

-  Fault  Isolation 

-  Recovery  Reconfiguration 

-  Adaptiveness 

-  Incorporation  of  Hew  Technology 

-  Coapetible  with  Old  Mechanisms 

-  Parameterization  Capability 

-  Flexible  Network  Control  Strategy 

-  Central  Control 

-  Distributed  Control 

-  Synchronous 

-  Asynchronous 

-  Cost /Complexity 

-  Non-recurring  Hardware  end  Software  Costs 

-  Recurring  Hardware  and  Software  Coats 

-  Support  Coats 

-  Haight,  Size,  Power 

With  the  use  of  e  Decision-Aiding  Algorithm,  each  of  those  criteria  and  their  sub-criteria  were  ranked 
in  order  to  achieve  e  weighting  by  which  a  protocol  could  be  evaluated.  As  can  be  seen  by  the  choice 
of  the  evaluation  criteria,  system  design  issues  were  considered  to  be  of  prime  importance  -  the  date 
bus  protocol  definition  should  be  accomplished  by  e  top-down  approach.  Although  not  specifically 
listed  as  criteria,  system  design  iasuas  such  as  system  control  procedures  and  executlve/opereting 
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system  Impacts  were  often  major  factors  in  setting  criteria  values.  Datailad  definitions  for  each  of 
the  evaluation  criteria  are  described  in  tha  following  paragraphs. 

Throughput/Response  -  Throughput  is  a  measure  of  the  rate  at  which  a  system  can  transfer  data  among  its 
terminals.  Response  time  is  primarily  a  function  of  the  flexibility  and  assignability  of  the 
allocation  scheme  which  has  implication  in  terms  of  throughput  and  data  latancy. 

-  Data  Latency.  This  is  the  time  delay  from  data  reception  at  a  transmitting  node's  data  link 
level  through  data  recaption  at  a  receiving  node's  data  link  level.  This  implies  transmission 
of  tha  data  across  tha  physical  bus  medium. 

-  Eff active  Link  Level  Data  Throughput.  This  criteria  addresses  the  issue  of  sustained  throughput 
of  data  from  data  link  level  between  two  nodes.  It  is  important  to  distinguish  between  actual 
user  data  throughput  as  opposed  to  percentage  utilization  or  loading  of  the  physical  transmis¬ 
sion  medium. 

Message  Structure.  The  overall  message  structure  should  support  a  system  in  which  any  task  can  reslda 
in  any  processor  at  any  time.  The  command,  address,  and  data  block  structure  should  allow  sufficient 
flexibility  to  handle  any  possible  task  or  the  future  expansion  of  the  system  to  new  tasks. 

-  Expandable  Addressing  -  A  provision  to  allow  system  expansion  either  -directly  or  Indirectly. 

-  Broadcast  Cspability  -  A  system  mode  by  which  messages  can  be  transmitted  to  all  terminals 
simultaneously. 

-  Block  Transfers  -  A  block  transfer  mode  of  variable  length  data  blocks. 

-  Content  Addressability  -  Accommodation  of  data  transfer  based  on  message  content  or  task. 

System  Integrity  -  The  degree  to  which  a  system  is  dependable.  Tha  ease  by  which  the  system  can  be 
testad  and  monitored  for  conformance  to  requirements. 

-  Monitorable.  A  failure  in  the  bus  allocation  mechanism  should  be  quickly  detected  and 
Immediate  recovery  initiated.  This  is  usually  accomplished  by  a  monitor.  The  bus  allocation 
method  should  be  straightforward  so  as  to  simplify  the  amount  of  hardware  required  in  the 
monitor  function. 

-  Testability.  This  criteria  addresses  how  well  the  protocol  supports  completeness  of  testing  and 
facilitates  repeatable  or  predictable  results  (i.e.,  transmission  of  massagas  on  tha  bus).  Tha 
main  idea  bahlnd  this  criteria  is  testing,  especially  in  the  case  of  larga,  complicated  avionic 
systems. 

-  Initialization.  This  criteria  is  a  measure  of  how  wall  a  bus  communication  system  supports 
initial  configuration  of  a  system  on  initial  powerup. 

-  Data  Link  Assuranca  of  Raceipt.  This  crltaria  addresses  the  lssua  of  how  wall  the  protocol 
supports  the  assurance  of  good  data  through  tha  data  link  leval  (ISO  lavel  2). 

Fault  Tolarance.  The  capability  to  endura  component  errors  and/or  failuras  without  causing  total 
systam  failure.  An  Important  aspect  of  fault  tolerance  is  recovary,  which  lncludas  fault  detection, 
fault  containment,  fault  isolation,  and  raconf lguratlon.  Hanca,  fault  tolerance  will  Include  the 
following  areas: 

-  Fault  detection  -  ability  of  a  systam  to  determine  the  occurrence  of  erroneous  oparatlon. 

-  Fault  containment  -  meaeure  of  the  extant  to  which  the  system  prohibits  armors  and/or  failuras 
from  propagating  from  the  source  throughout  the  system  (i.e.,  a  ripple  effect). 

-  Fault  isolation  -  isolation  of  a  failure  to  the  required  lavel  so  as  to  be  able  to  reconfigure. 

That  is,  to  isolate  a  failure  to  a  "component"  so  that  It  may  be  dieabled  or  switched  off  and 
the  system  reconfigured  without  that  componant. 

-  Reconfiguration  -  what  mechanisms  are  provided  and  how  easy  are  these  mechanisms  employad  to 
reconflgura  a  system  aftar  a  failure  has  baen  detected  and  leolated.  This  may  includa  the 
process  of  reassigning  processing  tasks  from  ona  proceeelng  component  to  anothar  to  accommodate 
a  failure  or  change  in  miselon  requirements .  It  neceesltates  reassigning  data  flow  paths. 

Adaptivanaes.  The  protocol  should  land  itsalf  to  flexibility.  It  should  allow  for  new  technology 
advancee  and  thair  companion  requirements . 

-  Incorporation  of  Raw  Technology.  This  criteria  addresees  tha  lssua  of  how  easy  the  protocol 
can  incorporate  new  technology  (i.a.,  fiber  optlce,  higher  bue  spaads,  broadband,  etc.). 

Potential  benefite  include  Improved  capability  and  performance  and  the  maturation  of  etondards. 

-  Compatible  with  old  mechanisms.  This  criteria  supports  thosa  elements  which  are  already  In 
existence  for  current  etandards  (hardwara,  eoftwara,  control  strataglae). 

-  Parameterization  Capability.  Thie  criteria  addresses  the  requirement  of  a  flexible  protocol 
davaloped  by  parameterizing  thosa  elements  which  can  be  ao  structured. 
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Flexible  Network  Control  Strategy.  Various  network*  currently  exist,  therefore,  a  common  data  bus  for 
these  network  would  prove  to  be  very  beneficial. 

-  Central  Control.  Tha  capability  to  ba  controlled  from  one  neater  -  be  It  stationary  or  non- 
statlonary. 

-  Distributed  Control.  Tha  capability  to  be  controlled  fron  many  points  in  a  system. 

-  Synchronous  Messages.  This  criteria  addresses  the  Issue  of  how  well  the  protocol  supports  the 
transmission  of  a  series  of  messages  at  a  known  aprlori  sequence  and  time  or  time  Intarval. 

-  Asynchronous  Messages.  This  criteria  addresses  the  Issue  of  how  well  the  protocol  supports 
allowing  nodes  on  tha  data  bus  to  transmit  a  message  whose  time  of  transmission  is  not  known 
aprlori.  This  criteria  Is  also  a  measure  of  how  well  the  protocol  supports  the  transmission  of 
priority  messages  requiring  Immediate  access  to  the  bus. 

Cost/Complexity.  Evaluation  of  protocol  against  this  criteria  should  take  Into  account  nonrecurring 
and  recurring  cost  areas.  This  should  Include,  as  a  minimum,  hardware  development  costs,  hardware 
fabrication  costs,  and  software/firmware  costs.  Issues  to  take  into  consideration  in  this  area  may 
Include  availability  of  hardware,  firmware  and  software  from  commercial  sources  as  opposed  to  new 
development  In  each  of  thesa  areas.  For  a  standard  approach  to  this  area,  cost  will  be  considered  to 
be  a  function  of  nonrecurring  costs  plus  a  fixed  number  of  units  times  recurring  costs. 

-  Non-recurring  Hardware  and  Software  Costs.  The  cost/complexity  of  development  of  the  hardware 
and  software  naceasary  to  support  the  protocol. 

-  Recurring  Hardware  and  Software  Costs.  Cost/Complexity  of  elements  In  production  after 
development. 

-  Support  Costs.  Cost  to  support  these  elements  once  In  the  field. 

-  Height,  Size,  Power.  Physical  requirements  of  the  data  bus  elements. 

4.  Protocols;  A  number  of  protocols  were  researched  In  the  literature,  the  following  list  organized 
by  categories  ware  Investigated: 

Fixed  Assignment 

Time  Division  Multiple  Access  (TDMA) 

Fraquancy  Division  Multiple  Access  (FDMA) 

Random  Assignment 

Aloha 

Carrier  Sense  Multiple  Access  (CSMA) 

Carrier  Sanaa  Multiple  Access  with  collision  detection  (CSMA/CD) 

Controlled  Assignment 
Central  Control 

Global  Scheduling  Multiple  Access  (GSMA) 

Roll  Call  Polling 

Split-Channel  Reservation  Multiple  Access  (SRMA) 

Distributed  Control 

Priority  Assignment 

Broadcast  Racognlalng  Accaaa  Mode  (BRAM) 

Assigned  Slot  Llstan-Befora-Talk 
Distributed  Scheduling  Multiple  Access  (DSMA) 

Token  Ring 
Token  Passing 

Fast  Information  Transfer  System  (FITS)  (n.b.  FITS  Is  an  enhanced  1553-typa  bus  with  mors 
flexible  addressing,  versatile  message  formatting  and  control  capability) 

In  order  to  raduca  auparfluous  analyaas,  tha  abova  Hat  of  protocola  was  initially  flltarad  basad  on 
afflclancy/data  latency.  Assumptions  asaociated  with  this  filtering  procass  wars  minimum  accaptabla 
bus  efficiencies  of  50I-60X  and  maximum  data  latanclaa  not  axcaedlng  2-3  normalised  packat  transmission 
times.  Since  much  of  tha  apaciflc  system  implementation  aspects  of  thase  protocols  has  not  bean 
completed ,  the  protocols  were  treated  aa  ganaric  types. 

Thara  wars  six  protocols  which  wars  found  to  meat  thla  initial  sat  of  factors: 

1.  Broadcast  Racognlalng  Access  Mods  (BRAM). 

2.  Carrier  Sanaa  Multiple  Accaas/colllalon  detection  (CSMA/CD). 

3.  Distributed  Scheduling  Multiple  Accaaa  (DSMA). 

4.  Fast  Information  Transfer  System  (FITS). 

5.  Split-Channel  Reservation  Multiple  Accaaa  (SRMA). 

6.  Token  Passing  (Logical  Ring) . 


Of  these  six,  only  three  bed  sufficient  information  available  to  produce  a  meaningful  enslyals.  These 
three  were  then  the  subject  of  the  more  detailed  analysis  described  below. 

1.  CSMA/CB. 

2.  FITS. 

3.  Token  Passing. 

5.  Evaluation  Method.  The  first  step  in  the  evaluation  process  was  to  subjectively  compare  each  of 
the  seven  major  criteria  against  each  other  (paired  comparisons) ,  reference  Figure  1A.  Through  this 
comparison,  a  weighting  value  was  obtained  for  each  criteria.  In  order  to  gain  additional  analysis 
insight,  within  each  major  critaria  the  sub-criteria  were  slmilerly  compared,  reference  Figure  IB. 

Each  protocol  was  then  eveluated  against  each  criteria  -  these  eveluatlons  were  subjective  and  con¬ 
sidered  scientific  and  engineering  judgement,  based  on  numerous  yeers  of  system  lntegrstion/archi- 
tacture/protocol  experience.  Upon  completion  of  these  evaluations,  two  methods  of  decision  making  were 
eppliad: 


1.  Linear  Additive  Method. 

2.  Maxi  Min  Principle. 


Under  the  Linear  Additive  Method,  the  subjective  judgement  for  each  protocol  was  multiplied  by  the 
weighting  factor  for  each  criteris  and  then  sdded  together  to  determine  the  total  value  for  each 
alternative  protocol.  The  largest  absolute  value  was  considered  to  be  the  choice. 
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Under  the  Maxi  Min  approach  the  weighting  value  and  the  judgement  factor  were  combined  for  each  alter¬ 
native  for  ell  criteria.  These  velues  ware  than  placed  into  a  decision  matrix  where  the  maxi  min 
principle  was  applied.  In  essence,  the  minimum  value  (regerdless  of  the  criteria)  for  each  alternative 
was  identified  end  from  these  mlnimums  the  maximum  value  was  identified  as  the  choice.  The  eltematlve 
with  the  maximum  minimum  value  wes  considered  the  choice  because  of  the  leest  risk. 


max1  min^j  C  (6^) 

6.  Results  of  Evaluation;  The  weighting  of  the  suberiterie  end  criteria  wes  performed  with  the 
results  shown  in  Teble  1. 


TABLE  1  -  WEIGHTED  VALUE 


.061  -  Throughput /Response 

.167  -  Effective  link  level  deta  throughput 
.833  -  Data  Latency 

.060  -  Mesaaga  Structure 

.146  -  Addressing  Capacity 
.372  -  Broadcase  Capeblllty 
.205  -  Block  Slsa 
.277  -  Content  Addressing 

.272  -  System  Integrity 
.1:9  -  Monitorable 
.447  -  Testable 
.058  -  Initialisation 
.376  -  Data  link  easurance  of  receipt 

.382  -  Fault  Tolerance 
.389  -  Fsult  Detection 
. 125  -  Fault  Containment 
.040  -  Fault  Isolation 
.446  -  Recovery  Reconfiguration 

.064  -  Adaptiveness 

.342  -  Incorporation  of  Haw  Technology 
.081  -  Compatible  with  old  mechanisms 
.577  -  Parameterization  Capability 

.123  -  Flexible  Hetwork  Control  Strategy 
.094  -  Central  Control 
.5(7  -  Distributed  Control 
. 136  -  Synchronous 
.203  -  Asynchronous 

.038  -  Cost/Complexity 

. 100  -  Don-recurring  Hardware  and  Software  costs 
.137  -  Recurring  Hardware  and  Software  costs 
.400  -  Support  Costs 
.3(3  -  Haight,  Slaa,  Power 

As  s  measure  of  the  integrity  of  the  weighted  comparison  process  an  index  for  the  consistency  of  the 
judgements  was  derived.  This  measure  should  be  lass  than  1.0  if  the  judgements  are  consistent.  Values 
greater  than  2.0  suggest  that  perhaps  the  process  should  be  repeated  with  mors  attention  paid  to  each 
judgement.  For  the  value  of  Table  l,  the  consistency  value  is  .2276  —  highly  consistent. 


19-6 


In  the  second  step  each  protocol  was  then  evaluated  against  each  sub-criteria  by  assigning  vslues 
ranging  between  0  and  1  -  a  large  nuaber  always  indicating  "more"  of  an  attribute.  Sub-criteria 
weighted  values  (1st  step)  were  then  multiplied  by  their  assigned  values  (2nd  step)  and  summed  to 
provide  the  major  criteria  values.  The  results  >re  indicated  in  Tsble  2. 


TABLE  2  -  PROTOCOL  EVALUATIONS 


CSMA 

FITS 

Token  Passing 

Throughput /Res pons e 

.767 

.549 

.467 

-  Effective  link  level  data  throughput 

.6 

.8 

.8 

-  Data  Latency 

.8 

.5 

.4 

Message  Structure 

.883 

.770 

.786 

-  Addressing  Capacity 

1 

.7 

.9 

-  Broadcast  Capability 

1 

1 

1 

-  Size  (Block 

.7 

.9 

.7 

-  Addressing  (Content) 

.8 

.4 

.5 

System  Integrity 

.346 

I 

.846 

-  Monitorable 

.6 

) 

1 

-  Testable 

.2 

1 

1 

-  Initislization 

.6 

1 

.3 

-  Data  link  assurance  of  receipt 

.4 

1 

.7 

Fault  Tolerance 

.784 

.768 

.739 

-  Fault  Detection 

1 

.8 

.8 

-  Fault  Containment 

.5 

.9 

.7 

-  Fault  Isolation 

.5 

.8 

.7 

-  Recovery  Reconfiguration 

.7 

.7 

.7 

Adaptiveness 

.824 

.774 

.594 

-  Incorporation  of  New  Technology 

.7 

.7 

.7 

-  Compatible  with  old  mechanisms 

.1 

.9 

.1 

-  Paramsterization  Capability 

1 

.8 

.6 

Flexible  Network  Control  Strategy 

.857 

.769 

.668 

-  Central  Control 

.2 

1 

.5 

-  Distributed  Control 

1 

.7 

.7 

-  Synchronous 

.5 

1 

.9 

-  Asynchronous 

.7 

.5 

Cost/Complexlty 

.634 

.81 

.733 

-  Non-recurring  Hardware  6  Software  coats 

.8 

.5 

.4 

-  Recurring  Hardware  4  software  costs 

.7 

.8 

.6 

-  Support  Costs 

.6 

.9 

.8 

-  Height,  Size,  Power 

.6 

.8 

.8 

Using  the  Linear  Additive  approach,  the  weighting  factor  was  applied  to  each  criteria  factor  and  the 
total  suamed  for  each  alternative.  The  results  ere  shown  below: 


CSMA/CD 

.676 

FITS 

.820 

Toksn 

Passing 

.737 

The  largest  number  indicates  the  alternative  vtilch  best  satisfies  ell  crlterie  -  FITS. 

Using  the  Maxi  Min  decision  principle,  e  matrix  of  the  combinatorial  product  for  each  criteria  egelnst 
ths  sltemative  protocols  Is  fiist  formed: 


CRITERIA 

CSMA/CD 

FITS 

TOKEN  PASSING 

Throughput 

.893 

.776 

.724 

Message  Structure 

.949 

.896 

.904 

System  Integrity 

.133 

1 

.728 

Fault  "clarence 

.522 

...°4 

.445 

Adaptiveness 

.917 

.89. 

.792 

Control  Strategy 

.875 

.79 

.705 

Cost /Complexity 

.885 

.945 

.920 

From  this  the  minimum  value  in  each  column  (alternative)  of  the  matrix  is  chosen. 

MINIMUM  MAXIMUM 

CSMA/CD  .133 

FITS  .494  .494 


Token  Passing 


443 


» 
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The  maximum  of  the  minimuaa  is  the  choice  because  this  represents  the  alternative  with  the  least  risk. 
FITS  vith  a  .494  value 

In  retrospect,  the  selection  of  a  high  speed  1553B-type  (FITS)  bus  has  many  inherent  attendant  advan¬ 
tages.  Included  are  auch  intangibles  as  (1)  broad  experience  data  base,  (2)  general  user  acceptabil¬ 
ity,  (3)  availability  of  design/support  tools  and  (4)  established  implementation  guidelines. 

7.  SUMMARY :  This  analysis  is  indicative  of  a  logical  approach  to  accomplish  the  selection  of  a  high 
speed  data  bus.  There  is  subjective,  scientific  judgement  involved  in  the  choice  of: 

1.  weighting  criteria 

2.  relative  weighting 

3.  protocol  va.  criteria  judgement 

However,  the  results  of  this  analysis  will  be  presented  to  the  AE9B  sub-committee  on  data  bussing.  It 
is  hoped,  that  these  judgements  will  be  refined  and  an  agreeable  set  of  criteria  determined.  Once  this 
is  accomplished,  candidate  bus  protocols  can  be  evaluated  in  a  systematic  manner  and  an  impartial 
standardized  bus  can  be  defined. 
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DISCUSSION 


F.W.Broecker,  Ge 

How  do  you  propose  to  decide  in  the  paired  comparison  process  what  figure  should  be  given?  What  are  the 
evaluation  criteria? 

Author’s  Reply 

At  this  time,  the  figure  given  is  determined  through  subjective  judgement.  However,  there  is  consideration  being 
given  for  using  paired  comparison  against  each  of  the  protocols  as  well  as  each  of  the  evaluation  criteria  in  the 
separate  categories. 


W.H.McKinlay,  UK 

It  would  be  interesting  to  know  whether  the  original  inputs  to  this  work  (the  overall  system  concept,  factors  to  be 
considered,  etc.)  were  objective;  results  of  studies  or  actual  experiment,  or  subjective;  opinion  or  general  beliefs 
about  future  systems.  The  method  itself  is  precise  and  therefore  the  quality  of  the  inputs  matters. 

Author’s  Reply 

The  final  inputs  for  this  analysis  will  be  determined  by  the  S  AE/AE9B  committee  on  high  speed  data  busing.  The 
initial  inputs  were  determined  by  various  US  Air  Force  contractual  efforts  as  well  as  an  Air  Force  panel  of  experts. 


M.Burford,  UK 

Having  proposed  a  screening  mechanism  to  aid  network  selection  and  illustrated  it  with  an  example,  have  you  had 
a  chance  to  establish  the  sensitivity  of  the  mechanism  to  an  erroneous  weighting  for  a  particular  or  group  of 
attributes? 

Author’s  Reply 

There  is  a  consistency  measurement  taken  to  assure  that  a  weighting  relative  to  one  factor  is  consistent  with  the 
relationship  to  the  other  factors. 
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AVIONICS  (AULT  TREE  ANALYZER 


SUMMARY 

The  long  awaited  era  o  ^reliable  aelf-dlagnoslng  avionics  la  at  hand.  Due  to  recent  technological 
idvances  In  microcomputing  and  large  scale  lntegratlon^CLBlf^  overhead  cost  of  flying  avionics  support 
unctions  have  been  minimized,  McDonnell  Dougla»*yF/A^I8  aircraft  allows  use  of  a  man-portable,  micro- 
irocessor-controlled,  ground-based  test  set  to  Isolate  avionic  failures  to  the  electronic  card  or  shop 
replaceable  assembly  (SRA).  Through  a  single  existing  connector  on  the  aircraft,  this  Avionics  Fault 
ree  Analyzer  (AFTA)  communicates,  exercises,  Interrogates,  and  diagnoses  the  Avionic  subsystems.  There 
ire  many  Instances  when  the  AFTA  not  only  Isolates  faults  in  the  electronics  but  also  In  the  aircraft 
wiring.  Largely  due  to  the  truly  distributive  processing  architecture  of  the  aircraft  and  the  modular 
design  of  the  avionics,  fault  detection  and  Isolation  well  beyond  the  Weapon  Replaceable  Assembly  (WRA) 
is  achieved  within  milliseconds.  Avionics  as  sophisticated  as  the  Flight  Control  System,  RADAR,  and  the 
Stores  Management  System  are  supported  quickly  and  efficiently  with  electronics  card  replacement  without 
Intermediate  level  ground  support  facilities. The  AFTA  is  currently  a  ground  based  device  f however^  the 
AFTA  function  will  be  incorporated  in  future/aircraft. 

The  required  hardware  for  an  AFTA  already  exists  In  contemporary  aircraft.  AFTA  Is  composed  of  a 
general  purpose  microcomputer  with  two  Input/output  Interfaces.  The  human  Interface  uses  a  plasma  dis¬ 
play  and  touch  panel  to  reduce  weight  and  Increase  ease  of  operation.  The  aircraft's  multipurpose  dis¬ 
plays  and  associated  programmable  menu  switches  would  satisfy  this  function.  The  aircraft  Interface  is 
a  derivative  of  MIL-STD-1553  avionics  multiplex  bus.  . . 

Increasing  density  of  computer  memory,  more  modular  designed  avionics,  and  the  use  of  very  large 
scale  integrated  (VLSI)  devices  will  allow  future  aircraft  to  fly  with  the  AFTA  function.  Ramifications 
Include  minimizing  the  need  for  Intermediate  avionic  repair  facilities,  Increased  aircraft  operational 
readiness,  a  decrease  In  aircraft  recurring  cost,  and  a  reduction  In  spares  Investment. 


Michael  E.  Harris 

AFTA  Subsystem  Manager 

McDonnell  Aircraft  Company 

F.  0.  Box  516 

St.  Louis,  Missouri  63166 


INTRODUCTION 


Since  1950  up  through  1970,  avionics  systems  were  designed  primarily  with  one  goal  in  mind.  That  is, 
to  satisfy  mission  operational  requirements.  Little  or  no  consideration  could  be  afforded  at  the  front 
end  of  the  design  cycle  to  support  an  ease-of-malntenance  concept  for  these  systems.  Consequently,  the 
support  task  was  performed  using  a  brute  force  philosophy  as  evidenced  by  the  physical  size  and  extended 
test  times  of  the  Ground  Support  Equipment  (GSE).  During  the  same  time,  however,  revolutionary  changes 
were  taking  place  In  the  electronics  Industry,  particularly  In  silicon  technology.  These  changes  were 
of  such  dynamism  as  to  literally  run  away  from  effective  avionics  applications  engineering.  Fortunately, 
today's  engineers  have  caught  up  with  these  advances  and  are  beginning  to  develop  avionic  systems  that 
do  In  fact  afford  consideration  to  their  support  as  well  as  meeting  demanding  operational  requirements. 
Today's  avionics  are  modular  to  the  electronic  card  level,  and,  more  significantly,  the  systems  are 
acquiring  a  reliable  self-test  facility. 

In  Just  the  past  few  years,  the  Importance  of  this  self-testing  facility  has  Increased  In  direct 
proportion  to  the  maintenance  cost  of  the  avionics  equipment.  With  the  Incorporation  of  very  large  scale 
Integration  (VLSI)  electronics,  the  bullt-in-test  (BIT)  function  contributes  less  performance  overhead 
than  In  the  past.  An  heuristic  conclusion  Is  that  the  more  effective  the  BIT,  the  less  sophisticated 
the  GSE  requirement.  There  Is  still  a  real  estate  trade-off  between  BIT  and  performance  both  in  hardware 
and  software.  However,  due  to  maintenance  economics,  the  VLSI  circuitry,  and  the  Ingenuity  of  the  con¬ 
temporary  engineer,  the  penalty  of  extensive  BIT  is  not  severe. 

The  McDonnell  Douglas  F/A-18  aircraft  Is  an  example  of  a  transitional  product  derived  from  the 
changing  technology.  The  F/A-18  Is  a  software  intensive,  digital  aircraft.  Its  avionic  system  architec¬ 
ture  Is  composed  of  two  "mission  computers"  and  over  two  dozen  subsystems  whose  well  defined  tasks  are 
controlled  by  the  mission  computers  through  a  central  communication  bus.  Each  of  the  avionic  subsystems 
are  computer  based  and  decoupled  from  one  another  except  via  digital  bua  communication.  The  subsystem's 
BIT  requirements  Included  fault  isolation  to  the  weapon  replaceable  assembly  (WRA,  i.e.,  black  box)  for 
98Z  of  the  faults.  The  contractor-furnished  subsystems  were  modularly  designed  such  that,  although  not 
a  contractual  requirement,  the  BIT  could  be  used  to  Isolate  faults  to  the  electronic  card  within  the  WRA. 
Tt La  «Ierfcxonb  aiswab] j  ta  usually  u  m  i  wuf  lepleceatle  eeeemt.'.j  (BRA)  the  mwfc!.** 

design  and  extensive  subsystem  BIT  became  the  foundation  for  a  sultcase-alzed  tester  called  the  Avionics 
Fault  Tree  Analyzer  (AFTA). 

The  AFTA  la  a  microprocessor  based,  general  purpose  computer  designed  to  execute  fault  Isolation 
programs.  These  programs,  one  for  each  WRA  or  system  to  be  tested,  are  commonly  referred  to  as  Fault 
Trees.  It  Is  these  Fault  Tree  programs  that  direct  the  processing  necessary  to  achieve  effective  fault 
isolation. 

f  During  the  extensive  flight  development  testing  of  the  F/A-18,  a  team  of  avionics  engineers  eval- 

!  uated  and  maintained  the  aircraft  avionics  without  sophisticated  GSE.  Their  tools  were  the  aircraft 

[  BIT,  llte  ability  to  IrtstAgsU  Cl*  MtejHSa'*  mMSjt j  by  iiebAw  oa-tuerd  mummy  iAwpect,  and  their 

| 
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knowledge  and  experience  of  the  avionics  they  designed  and  Integrated.  With  AFTA,  It  Is  now  possible  to 
store  the  accumulated  knowledge  of  these  avionic  engineers  for  the  purpose  of  fault  Isolation  to  the  SRA 
level.  The  AFTA  Is  programmed  to  automatically  perform  the  same  type  tests  and  logical  analysis  that  an 

With  b.«gU.  7  .a r j  .1  f/'A- 13  ■  >t  - .  ■  ulu  y^rfom..  tliicc  Lub  lauiX  Tret,  progrcuua 

are  developed  by  the  same  engineers  who  designed,  integrated,  and  supported  the  F/A-18  avionics  during 
development,  it  takes  sdvantage  of  the  combined  talents  and  experience  of  a  formidable  group  of  experts. 
Once  developed  and  programmed ,  simple  reproduction  of  the  AFTA  hardware  and  software  makes  these  combined 
talents  and  experience  available  to  any  AFTA  user.  Figure  1  illustrates  the  use  of  the  AFTA  at  the  air¬ 
craft.  The  resident  aircraft  built-in-test  will  isolate  to  the  WRA.  The  AFTA  will  be  connected  to  the 
aircraft  for  both  power  and  communication.  AFTA  will  isolate  to  the  SRA  and/or  the  aircraft  wiring, 
hltxKng  the  maiUMudiM  rtn  a l  l»<-  flfulliAfet  Tbs  (*v  nftj  will  U  twaoeed  ft\».  IU  el.crr 

and  the  defective  SRA  replaced  in  a  sheltered  area.  The  repaired  WRA  is  determined  ready  for  issue  (RFI) 
by  re-running  the  AFTA  program  or  successfully  performing  the  aircraft  built-in-test.  The  entire  repair 
sequence  is  estimated  to  consume  less  than  30  minutes. 


BIT  Fsliure  Indication 


OMMUM 

FIGURE  t 
AFTA  USAGE 


AFTA  MECHANIZATION 

With  the  advent  of  the  microprocessor  and  other  large  scale  integrated  (LSI)  electronic  components, 
the  text  book  design  of  a  truly  distributive  and  efficient  computer  architecture  for  aircraft  control 
became  feasible.  The  F/A-18  is  a  practical  implementation  of  this  concept.  The  F/A-18  has  a  higher  per¬ 
centage  of  software  controlled  electronics  than  sny  other  existing  aircraft.  Due  to  VLSI  electronics,  it 
is  possible  and  desirable  to  distribute  the  avionic  tasks  to  subsystems  coupled  by  a  common  communication 
bus  structure.  Each  subsystem  controls  its  functions  by  its  dedicated  processor(s).  The  subsystem  reports 
or  controls  its  processes  under  the  direction  of  a  master  processing  unit  which  communicates  with  all  of 
the  subsystems.  In  the  F/A-18  aircraft,  this  master  processing  unit  is  a  pair  of  Mission  Computers.  The 
communication  link  is  a  Manchester  encoded  serial  bus  designed  around  the  MIL-STD-1553B.  Although  not  a 
requirement,  the  two  underlying  concepts  of  LSI  and  extensive  software  control  forced  modular  designs 
within  the  avionic  subsystem.  The  many  tasks  a  subsystem  was  responsible  for  were  designed  in  modular 
form  (an  electronic  card).  The  AFTA  concept  is  based  upon  modular  designed  avionic  subsystems  and  a 
cosmon  communication  bus  between  the  subsystems.  Figure  2  is  a  simplistic  representation  of  the  F/A-18 
avionics  system  and  the  Avionics  Fault  Tree  Analyser.  The  AFTA  hardware  requirements  are  a  communication 
link  compatible  with  the  avionics  and  a  computer  to  test  and  control  the  subsystems. 

The  AFTA  must  be  physically  small  and  capable  of  controlling  the  avionics  in  real  time.  Because 
the  AFTA  is  to  be  used  at  the  aircraft,  and  aircraft  down  time  must  always  be  minimised,  the  AFTA  must 
be  easily  moved  to  and  connected  to  the  aircraft.  The  AFTA  receives  its  power  and  avionics  miltiplex 
bus  interface  through  two  existing  aircraft  connectors  in  the  F/A-18's  nose  wheel  well.  The  AFTA 
requirements  of  light  weight  and  short  test  timas  have  been  accomplished  as  a  result  of  the  current  LSI 
technology  and  extensive  avionics  software.  Figure  3  is  a  photograph  of  the  Prototype  AFTA.  The  proto¬ 
type  AFTA  is  itself  a  distributed  processing  test  system.  A  simplified  block  diagram  of  the  AFTA  is 
presented  in  Figure  4.  The  main  processing  unit  (MPU)  is  a  microprocessor  based,  single  board  computer 
with  basic  instruction  cycle  of  8.24  x  10“  seconds.  AFTA  includes  96,000  8-bit  bytes  of  read  only 
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AFTA-Avionics  communication  is  accomplished  by  a  single  microprocessor  controlled  MIL-STD-1553B 
communication  controller  called  the  Avionic  Multiplex  Bus  (AVMUX)  controller.  The  AVMDX  controller  con¬ 
verts  the  message  stored  in  common  memory  to  the  biphase  Manchester  encoded  signal  required  of  the  avionics. 
Figure  5  diagrams  the  signal  characteristics. 


ONE  BIT  TIMB 


FIGURE  5  DATA  ENCODING 


The  operator  control  is  accomplished  through  a  neon  display  and  an  infrared  touch  panel.  The  neon 
display  is  rugged,  light  weight  and  readily  interfaced  to  a  microprocessor  based  MPU.  Displaying  up  to 
480  alphanumeric  characters  on  a  4  x  8  inch  front,  this  operator  input/output  device  receives  operator 
inputs  or  displays  test  results.  The  display  features  twelve  (12)  rows,  forty  (40)  columns,  weighs  10  lbs, 
and  can  withstand  a  fifteen  (15)  G  shock. 

Attached  to  the  face  plate  of  the  display  is  an  infrared  (optical)  light  grid.  This  light  grid  is 
the  operator's  main  input  media.  The  AFTA  will  display  an  operator  action  and  offer  options  in  the  form 
of  an  underlined  (scored)  choice  such  as : 

DO  YOU  WISH  TO  CONTINUE? 

YES  NO 

The  operator  will  touch  the  appropriate  selection  disrupting  two  orthogonal  light  beams.  Corresponding 
coordinates  are  sent  to  the  MPU  and  the  computer  program  responds  accordingly.  There  are  240  light  inter¬ 
sections  in  the  4x8  inch  display  area.  The  display  and  touch  panel  allows  software  programmable 
"switches",  thereby  reducing  front  panel  spatial  and  weight  parameters  and  at  the  same  time  increases  its 
versatility.  In  addition,  the  operator  need  not  relate  an  instruction  (or  desire)  from  the  display  media 
to  dexterous  motion  such  as  typing.  He  will  read  the  Instructions  and  touch  the  option.  Figures  6 
through  11  portray  a  typical  sequence  of  events  from  the  display.  Recall  that  the  underlined  words  are 
the  only  valid  reaponsea  for  that  particular  diaplay.  A  light  beam  intersection  broken  at  any  not  under¬ 
lined  area  will  be  Ignored  by  the  MPU. 

Upon  application  of  power,  the  AFTA  will  perform  a  self  test  designed  to  fault  isolate  Itself  to  the 
SRA.  In  many  instance! ,  the  fault  isolation  extends  to  component  groups. 

All  displays  are  standardized.  The  first  line  is  reserved  for  system  messages  including  the  real 
time,  date,  Julian  date,  day,  and  current  display  option.  On  the  second  line,  operator  options  are  avail¬ 
able  if  applicable.  The  operator  may  select  a  program  from  BUBBLE  (bulk  storage),  PRINT  the  current 
diaplay,  go  to  NEXT  display,  change  number  base,  or  ABORT  the  current  test  sequence.  The  display  area 
below  the  broken  line  is  used  for  menus  or  is  available  to  the  WRA  fault  tree  designer  for  presenting 
operator  instructions,  test  results,  etc.  At  turn-on,  after  successful  completion  of  the  AFTA  self  test, 
the  top  level  menu  is  displayed  as  in  Figure  6.  A  brief  description  of  each  option  follows: 
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MMP  TEST:  The  aircraft's  Maintenance  Monitor  Panel  (MMP) ,  located  in  the  nose  wheel  well, 

will  display  a  number  corresponding  to  a  defective  WRA  as  determined  by  the  air¬ 
craft's  self  test.  Selecting  the  AFTA  menu  option  MMP  TEST  will  allow  the  main¬ 
tenance  crew  to  enter  the  MMP  code  into  APTA.  AFTA  will  then  execute  the  appro¬ 
priate  fault  tree  program  to  confirm  the  WRA  failure  and  fault  isolate  to  the  SRA, 

WRA  TEST:  Upon  this  selection,  the  next  display  will  be  Figure  7  comprising  a  list  of  WRA's 

to  be  fault  isolated.  Figure  7  is  not  the  entire  list  of  fault  trees,  but  is 
included  here  for  discussion  purposes  only. 


MEM  INSPECT:  Memory  inspection  into  the  WRA  under  test  is  performed  automatically  by  the  fault 
tree  program.  The  MEM  INSPECT  selection  will,  however,  allow  manual  interrogation 
in  four  number  bases:  octal,  hexidecimal,  binary,  and  decimal. 

HELP:  The  AFTA  is  designed  to  fault  isolate  the  F/A-18  with  little  or  no  training  on  the 

use  of  AFTA.  However,  upon  selecting  HELP,  several  pages  of  information  are  dis¬ 
played  educating  the  operator  on  the  use  of  AFTA  and  the  maintneance  of  the 
aircraft. 


SELF  TEST:  As  mentioned  previously,  upon  power  initiation,  the  AFTA  will  perform  a  self  test. 

An  operator  initiated  self  test  is  also  available.  After  selection,  a  submenu  is 
displayed  allowing  the  operator  to  select  portions  of  the  AFTA  to  be  investigated. 

MONITOR:  This  option  is  included  in  the  preproduction  models  only.  The  MONITOR  option  is 

password  controlled  and  allows  such  engineering  evaluations  as  change  register, 
modify  AFTA  memory,  and  break  point  insertion. 


As  indicated  earlier.  Figure  7  is  a  result  of  touching  WRA  TEST  on  the  top  level  menu  of  Figure  6. 
The  display  of  Figure  7  is  incomplete.  The  following  lists  the  WRA's  fault  Isolated  to  the  electronic 
module  (SRA) : 
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HEAD  UP  Display  (HUD) 

Multipurpose  Display  Indicators  (MDI) 
Multipurpose  Display  Repeater  Indicator 
(MDRI) 

Maintenance  Signal  Data  Recorder  (MSDR) 
Maintenance  Signal  Data  Converter  (MSDC) 
Communication  Set  Control  (CSC) 
Horizontal  Situation  Display  (HSD) 
Inertial  Navigation  System  (INS) 

UHF/VHF  Communication  Set  (Comm  1,  2) 
Data  Link  (DL) 

Engine  Monitor  Display  (EMD) 

Stores  Management  Processor  (SMP) 

Linear  Electrical  Accelerometer 


Gun  Decoder  (GD) 

Wing  Decoder  (WD) 

Pylon  Decoder  (PD) 

Fuselage  Decoder  (FD) 

Up  Front  Control  (UFC) 

Mission  Computer  (MC) 

RADAR  Transmitter 

RADAR  Data  Processor 

RADAR  Receiver  Exciter 

RADAR  Antenna  System 

Flight  Control  Computer  (FCC) 

Air  Data  Computer 

Rate  Gyroscope 


This  list  of  WRA' 8  is  portrayed  on  several  AFTA  display  pages.  The  operator  selected  "NEXT"  to 
change  pages. 

After  selecting  the  Flight  Control  System  (FCS)  fault  tree  programs,  the  AFTA  will  instruct  the 
operator  to  turn  FCS  power  on.  The  operator's  next  evolution  will  be  to  ensure  there  is  sufficient 
hydraulic  energy  to  thoroughly  test  the  FCS.  Upon  connecting  the  hydraulic  carts  or  turning  on  both 
engines,  the  operator  will  touch  NEXT  to  commence  FCS  testing.  Less  than  three  minutes  later,  the 
AFTA  will  display  the  defective  SRA,  or,  as  in  the  example  of  Figure  10,  further  instructions  are  given 
to  measure  aircraft  wire  continuity.  Figure  11  informs  the  operator  of  the  results  of  the  FCS  fault 
diagnostics. 


The  AFTA  software  is  partitioned  into  the  real  time  operating  system  used  to  control  the  AFTA  hard¬ 
ware  and  the  application  software  for  avionics  fault  isolation. 

The  key  to  any  modern  portable,  real  time  computing  system  is  the  reduction  of  overhead;  thereby 
forcing  a  small  and  efficient  operating  system.  The  AFTA  operating  system  is  designed  around  the  classi¬ 
cal  hierarchical  machine  depicted  in  Figure  12.  The  kernel  is  composed  of  the  modules  of  the  system 
that  reside  within  the  machine,  as  opposed  to  those  that  operate  as  process  layers.  The  kernel  has 
responsibility  for  processor  management,  memory  management,  device  assignments,  and  file  management. 

A  short  description  of  each  process  group  follows ; 

o  Command  Interpreter  -  The  purpose  of  this  process  is  to  identify  an  operator  request  and  to 
determine  and  activate  the  appropriate  task  to  act  on  that  request. 

o  Fault  Tree  Application  Processes  1-N  -  These  "jobs"  are  not  part  of  the  operating  system  but 
are  the  vehicle  by  which  the  avionics  is  fault  isolated.  They  will  be  discussed  in  detail  later 
in  this  paper, 

o  AFTA  Self  Test  -  The  purpose  of  this  process  is  to  test  the  AFTA  hardware,  e.g.,  tape  interface, 
RAM  and  ROM  for  faults  and  to  inform  the  operator  of  the  faults  detected. 

o  Memory  Inspect  Process  -  The  purpose  of  this  process  is  to  validate,  request  from  Memroy  Inspect 
Utility,  and  output  to  the  Display  Manager  via  the  Kernel  the  contents  of  an  operstor  selected 
address  in  an  operator  selected  avionic  subsystem. 
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o  Initlaliie  Process  -  The  purpose  of  this  process  is  to  set  the  operating  system  of  the  AFTA  to 
an  initial  state  from  which  processing  of  any  subsequent  AFTA  function  will  commence. 

o  System  Integrity  Check  Process  -  The  purpose  of  this  process  is  to  interrogate  all  avionic  sub¬ 
systems  interfaced  with  the  AVIONICS  MUX  BUS  for  status.  This  process  interfaces  with  the  AVIONICS 
MUX  BUS  process. 

o  Mission  Support  Process  -  The  purpose  of  this  process  is  to  enable  operator  development  support 
and  control  of  the  F/A-18  Mission  Computers  from  non-avionics  mux  bus  channels.  This  process 
will  directly  control  dedicated  hardware.  In  this  respect,  this  process  is  more  accurately  re¬ 
ferred  to  as  a  driver. 

o  Memory  Load/Verify  Process  -  The  purpose  of  this  process  is  to  enable  loading  programs  into 

selected  avionic  processors  interfaced  with  the  AVIONICS  MUX  or  Mission  Computer  support  channel. 

It  shall  additionally  enable  the  download  of  selected  USA's  operational  flight  programs  to  mass 
stor*  ,  for  laboratory  evaluation. 

o  Mass  Storage  Control  Process  -  The  purpose  of  this  process  is  both  to  provide  the  user  facility 
for  transfer  of  data  to  and  from  the  mass  storage  media  and  to  control  the  transfer  of  that  data. 

o  Avionics  Mux  Bus  Process  -  The  purpose  of  this  process  is  to  control  access  to/from  avionic  pro¬ 
cessors  connected  via  the  AVIONICS  MUX  BUS.  This  process  also  interfaces  directly  with  the 
AFTA  AVIONICS  MUX  BUS  hardware. 

o  Display  Process  -  This  process  is  to  control  the  input  to  and  output  from  the  plasma  display/ 
touch  panel.  It  shall  determine  valid  key  depressions  and  which  task  shall  receive  notification 
of  a  key  depression.  This  process  controls  the  display  of  pages  of  texc,  system  status  messages, 
menus,  control  keys,  and  the  contents  of  avionics  memory. 

o  Key  Process  -  The  purpose  of  this  process  is  to  accept  operator  input  in  the  form  of  key  depres¬ 
sions  from  the  display  and  inform  the  Display  Process  of  those  key  depressions. 

o  Printer  Process  -  The  purpose  oc  this  process  is  to  control  the  printing  of  the  contents  of  the 
display  screen  to  an  external  printer.  This  process  will  also  act  as  the  printer  driver  con¬ 
trolling  the  transfer  of  data  and  issuing  commands  to  the  external  printer. 
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Except  for  the  nucleus  (kernel),  the  processes  are  coded  in  a  high  level,  inherently  structured, 
programing  language.  Each  task  is  composed  of  one  or  more  modules  of  200  lines  or  less.  The  modules 
are  described  by  Nassi-Schneiderman  Charts  to  ensure  a  structured  style. 

Due  to  the  comprehensive  nature  of  the  F/A-18  BIT  and  its  integrated  system  architecture,  this 
suitcase-sized  tester  can  support  the  aircraft  without  the  expense  of  the  typical  intermediate  level 
maintenance  facility.  The  essence  of  the  AFTA  is  the  fault  tree.  A  fault  tree  is  in  flow  diagram  format 
and  it  illustrates  the  procedures  necessary  to  fault  isolate  to  the  electronic  card.  As  stated  previously, 
the  effectiveness  of  the  fault  trees  to  isolate  a  WRA  failure  to  the  SRA  level  is  highly  dependent  on  the 
avionics  design.  The  McDonnell  Aircraft  requirement  that  BIT  detect  and  isolate  (to  the  WRA)  98%  of  the 
faults  with  a  99%  confidence  caused  most  of  the  F/A-18  equipment  designers  to  develop  an  architecture 
allowing  fault  isolation  to  the  SRA  group.  The  aircraft  system  design  incorporates  a  central  (and  redun¬ 
dant)  bus  for  inter-computer  communication.  Each  serial  bus  is  operated  in  a  half-duplex  fashion  using 
the  Manchester  encoding  format.  The  two  mission  computers  are  bus  masters.  All  communication  with  the 
avionic  subsystems  is  through  the  Mission  Computers  using  this  Manchester  bus  (Avionics  Multiplex  Bus). 

The  Avionics  Multiplex  Bus  is  therefore  an  Information  window  into  the  avionic  subsystem.  The  AFTA 
replaces  the  Mission  Computers  as  the  bus  master  and  communicates  directly  with  the  subsystem.  The  AFTA 
has  the  capability  of  inspecting  the  internal  memories  of  the  avionics  and  controlling  the  avionics  to  the 
same  extent  as  the  Mission  Computers.  It  is  the  avionic  BIT  effectiveness,  the  logical  evaluation  of  the 
results,  and  inspection  of  the  internal  memories  of  the  avionics  that  make  up  the  avionic  fault  trees. 

Most  of  the  F/A-18  avionics  can  be  fault  isolated  to  the  SRA  with  only  these  tools.  Some  WRA'a  require 
more  imaginative  efforts. 

Some  avionic  equipments  are  designed  to  take  advantage  of  the  existence  of  the  processor  and  its  non¬ 
volatile  memory  which  was  included  as  part  of  their  functional  design.  In  these  instances,  the  operational 
program  is  removed  and  a  diagnostic  routine  is  loaded  in  its  place.  In  such  a  scenario,  the  AFTa  is  pro¬ 
grammed  to  load  the  diagnostic  routines,  fault  isolate  to  the  SRA  level,  and  to  reload  the  operational 
program  in  the  WRA  while  installed  in  the  aircraft.  A  third  method  for  fault  isolation  employs  less 
deterministic  methods. 

A  few  of  the  subsystems  are  not  directly  connected  to  the  avionics  multiplex  bus,  making  the  fault 
tree  philosophies  mentioned  less  effective.  For  these  systems,  the  fault  tree  designer'3  experience  has 
a  more  predominent  role.  In  many  of  these  equipments,  an  analysis  of  the  functional  (or  mal-functionlng) 
Input  t  and  lUtpwtK  tabued  on  a  InovleAgb  vl  ttie  4<l!  oieSidiilt  at  ton  I  r 

be  drawn  as  to  which  SRA  is  at  fault.  The  AFTA  is  loaded  with  the  necessary  system  information  and 
programmed  to  perform  this  logic  function. 

These  fault  isolation  methods  are  illustrated  in  Figure  13.  The  AFTA  is  programmed  to  automatically 
perform  the  same  type  tests  and  the  logical  analysis  an  engineer  with  several  years  of  F/A-18  development 
experience  would  perform  manually.  This  is  the  foundation  of  the  fault  trees.  Since  the  AFTA'e  fault 
trees  are  developed  and  verified  by  the  same  engineers  who  designed,  integrated,  and  supported  the  F/A-18 
avionics  through  development  and  into  production,  it  takes  advantage  of  the  combined  talents  and  experience 
of  not  only  the  McDonnell  Aircraft  experts  but  also  the  equipment  designers.  Figure  14  is  an  abbreviated 
fault  tree  example.  As  can  be  seen  from  the  example,  the  fault  isolation  effectiveness  is  not  perfect. 
There  exist  SRA  interdependencies  within  most  of  the  avionics  forcing  unwanted  ambiquity  groups. 
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Aa  illustrated  in  Figure  14,  the  AFTA  will  initiate  the  WRA  BIT  by  using  the  AVMUX.  If  the  VBA  does 
not  respond,  the  appropriate  SKA's  are  determined  defective.  When  WBA  BIT  completes,  the  AFTA  will  auto¬ 
matically  memory  inspect  selected  WRA  addresses.  The  contents  of  these  addresses  relate  to  SRA(s)  or 
SartSflretre  opetfctLt  tire  atfoti  '  t«-e  It*  1’irt  tAM  tlfcA.  «  fcOCT.u.l><€  C-«!t  IOC  «Wdh 

decision  blocks. 


nounc  is 

FAULT  TMC  EXAMPLE 


The  fault  tree  designers’  ground  rules  were  simple  and  limited  in  an  effort  to  increase  fault  detection 
and  decrease  ambiguity  sometimes  at  the  expense  of  uniformity.  The  objective  of  the  AFTA  and  therefore  the 
fault  tree  designers  was  to  repair  the  aircraft  avionics.  Secondary  but  important  desirables  included  mini¬ 
mising  ambiguity  groups  and  reducing  dependencies  on  other  WRA's. 

The  avionic  subsystems  possess  varying  architectures ,  consequently  a  "standard"  fault  tree  format  is 
impossible.  Although  the  fault  trees,  in  flow  diagram  format,  appear  to  be  of  the  same  form,  they  are 
highly  dependent  on  the  Individual  nsturs  of  equipment  under  test  and  therefore  totally  unlqus  in  approach. 
The  flight  control  system  fault  tree  greatly  depends  on  the  exceptional  flight  control  system  self  test 
and  aircraft  memory  inspection.  With  these  two  tools,  the  fault  tree’s  expected  ambitulty  averages  less 
than  two  SRA's.  In  this  example,  some  of  the  conventional  assumptions  In  testing  are  unnecessary.  For 
example,  the  flight  control  system  fault  tree  calls  out  defective  aircraft  wires  and  even  Isolates  multiple 
faulures.  The  AFTA  fault  trees  will  Inform  the  operator  of  all  SRA’s  that  could  cause  the  fault  listed  in 
descending  probability  of  occurrence.  In  this  way,  repair  of  the  aircraft  is  inevitable. 

The  use  of  peripheral  WRA's  was  discouraged  while  testing  a  WRA.  Where  peripheral  WRA's  are  required 
to  perform  a  comprehensive  examination  of  the  unit  under  test  (UUT) ,  two  stages  of  diagnostics  were  employed. 
The  first  phase  allowed  the  use  of  the  peripheral  WRA  and  the  second  phase  did  not  make  this  allowance.  As 
a  result,  a  limited  test  could  still  be  performed  regardless  of  ths  existence  or  condition  of  a  dependent 
WRA.  An  example  of  such  an  arrangement  can  be  seen  on  the  simplified  aircraft  avionics  block  diagram  of 
Figure  2.  The  Multipurpose  Display  Group  (MDC)  is  a  subsystem  interfacing  directly  with  the  Avionics  Multi¬ 
plex  Bus,  and  therefore  the  AFTA.  However,  the  MDG  possesses  output  circuitry  that  controls  the  Head-Up- 
Display  (HUD).  The  MDG  fault  tree  will  use  the  HUD  Interface  if  the  HUD  is  available;  however,  a  test  of 
the  MDG  avionics  is  performed  regardless  of  the  condition  or  even  the  existance  of  the  HUD. 

Because  the  AFTA  is  used  at  the  aircraft  (0-Level  Maintenance),  aircraft  use  must  bs  minimised  to 
maintain  high  operational  readiness.  Few  of  the  fault  trees  require  more  than  five  minutes  for  execution. 
When  a  more  comprehensive  functional  test  becomes  too  long,  that  test  is  performed  at  the  operator's  dis¬ 
cretion.  An  example  is  the  Inertial  Navigation  Set  (IMS).  Fault  Isolation  takes  a  few  seconds;  however, 
it  may  be  desirable  to  perform  a  drift  check  consuming  48  minutes.  The  operator  is  given  the  option  of 
performing  any  test  over  and  above  the  fault  isolation  requirements.  Table  I  lists  approximate  fault 
tree  execution  times. 

The  fault  tree  originator  was  not  allowed  access  points  into  the  WRA  such  as  test  connectors  or  external 
stimuli.  No  aircraft  doors  are  opened  as  a  result  of  using  the  AFTA  except  to  repair  the  faulty  WRA.  Aa 
mentioned  earlier,  the  AFTA  connects  to  existing  nose  wheel  well  connectors  on  ths  aircraft  for  both  power 
and  avionic  multiplex  bus  access.  The  fault  tree  designer  did  have  the  controls  in  the  cockpit  at  his 
disposal.  Many  of  the  WRA's  under  test  receive  stimuli  from  the  aircraft  aa  a  result  of  operator  activities 
within  the  cockpit. 
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AFTA'S  EFFECTIVENESS 


How  effective  is  the  AFTA?  Significant  effort  has  been  expended  to  develop  a  theoretical  prediction 
on  AFTA's  effectiveness.  The  parameters  available  for  this  study  included  the  WRA  fault  tree,  the  BIT 
philosophy,  and  the  expected  failure  rates  of  the  WRA's  and  the  SRA's.  At  this  writing,  a  satisfactory 
algorithm  tracking  the  empirical  data  has  not  been  discovered.  However,  the  empirical  data  gathered  is 
very  encouraging. 

TABLE  I 


APPROXIMATE  AFTA  EXECUTION  TIMES  INCLUDING 
APPROPRIATE  OPERATOR  ACTION  FOR  SELECTED  WRA' 8 


WEAPON  REPLACEABLE  ASSEMBLY  (WRA) 

TEST  TIME 

Air  Data  Computer  (ADC) 

Milliseconds 

Armament  Computer  (AC) 

2 

minutes 

Wing  Tip  Decoders  (WD) 

2 

minutes 

Pylon  Decoder  (PD) 

2 

minutes 

Fuselage  Decoder  (FD) 

2 

minutes 

Gun  Decoder  (GD) 

2 

minutes 

Head  Up  Display  (HUD) 

1 

minute 

Multiple  Display  Indicator  (MDI) 

2 

minutes 

MDI  Repeater  (MDRI) 

2 

minutes 

Maintenance  Signal  Data  Recorder  (MSDE) 

3 

minutes 

Maintenance  Signal  Data  Converter  (MSDC) 

3 

minutes 

Control  Converter  (CSC) 

2 

seconds 

Horizontal  Situation  Indicator  (HSI) 

2 

minutes 

Engine  Performance  Panel  (EPP) 

2 

seconds 

Up-Front-Control  (UFC) 

2 

seconds 

Flight  Control  Computer  System  (FCS) 

3 

minutes 

Rate  Gyro  Assembly 

3 

minutes 

Linear  Accelerometer  Assembly 

3 

minutes 

There  are  two  AFTA's  at  Cold  Lake,  Canada  supporting  seven  of  the  avionic  subsystems  for  seven  air¬ 
craft.  The  same  two  AFTA's  will  be  supporting  45  aircraft  in  Canada  by  October  1984.  Eight  preproduction 
AFTA's  containing  fault  tree  programs  for  16  avionic  subsystems  will  be  delivered  this  year  to  three  U.S. 
Navy  bases  in  support  of  the  F/A-18.  To  evaluate  the  effectiveness  of  the  AFTA,  an  engineering  data  base 
has  been  designed  and  implemented.  It  is  through  this  data  base  that  AFTA's  effectiveness  will  be  deter¬ 
mined.  The  data  base  will  be  updated  by  field  personnel  through  a  central  management  system.  The  data 
and  any  related  reports  will  be  accessible  in  real  time  to  all  AFTA  users.  This  relational  data  base 
facilitates  a  variety  of  reports  that  may  be  sorted  and  grouped  by  any  field  and  to  any  level.  Tbs 
record  definition  follows: 

WRA  NAME  (5  bytes)  -  Character  designator  for  the  WRA  being  tested.  The  currently  allowed  names  are 
INS,  HSD,  ML'I,  ADC,  FCS,  HUD,  CSC. 

WRA  SERIAL  NUMBER  (14  bytes)  -  Vendor  serial  number  for  the  unit  under  test. 

DATE  (11  bytes)  -  Initial  date  which  testing  began  on  the  unit  under  test, 

USER  (22  bytes)  -  Name  of  person  running  test. 

TEST  SCHEME  (3  bytes)  -  Method  by  which  test  was  run. 

ITB  Integrated  Teat  Benches 

A/C  Aircraft  Testing 

ATS  Automatic  Test  Equipment 

SIM  Aircraft  Simulator 

TAIL  NUMBER  (7  bytes)  -  Tail  number  for  aircraft  on  which  test  was  run.  Valid  only  if  TEST  SCHEME 
is  A/C. 

LOCATION  (3  bytes)  -  Site  at  which  test  was  run. 

LKR  Lamoore 

ETR  El  Toro 

CFD  Cecil  Field 

CLC  Cold  Lake  Canada 

WRA  TIME  TO  REPAIR  (3  byte-;  -  Time  to  repair  e  WRA  including  time  waiting  for  parts,  time  on  aircraft, 
and  time  replacing  SRA's.  This  entry  is  only  '-slid  if  this  data  base  entry  has  a  classification  of  HIT 
(the  WRA  was  repaired  by  the  replace  a  tion  below).  Otherwise,  this  entry  should  have  a  value  of  zero. 

TIME  ON  AIRCRAFT  (3  bytes)  -  Ti«e  spent  on  eircraft  in  order  to  obtain  the  replace  action  found  below. 
This  record  is  a  measure  of  aircraft  usage. 

SRA  COUNT  (2  bytea)  -  Number  of  SRA’s  celled  out  by  repiece  action. 

PRIORITY  (2  bytes)  -  Priority  of  SRA  which  failed.  For  example,  if  Al,  A3,  and  A4  are  called  out  in 
that  order  and  A3  failed,  then  the  priority  is  2.  If  the  failed  SRA  is  not  in  the  replace  action,  then 
the  priority  is  0. 

CLASSIFICATION  (3  bytes)  -  The  classification  of  the  diagnosis. 

CND  Could  Not  Duplicate  the  fellure  squawked 
HIT  AFTA  correctly  diagnosed  the  failure 

MIS  AFTA  Incorrectly  diagnosed  the  failure 

FAILED  SRA  (3  bytes)  -  Up  to  three  letter  designator  of  teiled  SRA.  For  example,  A13. 

SRA  LIST  (30  bytes)  -  The  list  of  SRA’s  AFTA  called  out  in  this  replace  action.  Unused  entries  are 
set  et  0. 

OOmENTS  (20  bytes)  -  User  option. 

Improving  aircraft  operational  readiness,  reducing  spares  density  in  tha  pipeline,  and  reducing  atain- 
tenance  costs  have  augmented  the  AFTA’s  popularity.  The  AFTA  concept  will  be  Integrated  into  the  avionics 
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in  future  aircraft.  Fault  isolation  to  the  SRA  level  should  and  will  be  accomplished  on  board  and  in 
real  time.  As  VLSI  devices  become  more  versatile,  fault  isolating  a  large  percentage  of  faults  to  “ 
single  SRA  within  the  aircraft  is  a  certainty.  This  fault  detection  and  isolation  capability  will  drasti 
cally  reduce  the  need  for  second  level  maintenance,  thereby  allowing  significant  support  savings. 

Aa  oart  of  the  preplanned  product  improvement  program  plan  for  the  F/A-18  weapon  system,  a  Flight 
Incident  Recording/Aircraft  Monitoring  System  (FIRAMS)  was  proposed.  Although  the  FIRAMS  primary  purpose 
is  flight  incident  and  maintenance  data  recording,  it  has  all  of  the  components  of  an  on  board  AFT A. 

The  FIRAMS  provides  communication  through  the  AVMUX  and  it  contains  sufficient  memory  for  the  fault  t.ee 
urograms.  The  next  quantum  improvement  in  avionics  support  must  be  in  the  avionics  systems  themselves. 
Incorporation  of  the  AFTA  concept  in  the  proposed  FIRAMS  need  not  and  should  not  be  limited  in  application 
to  the  avionics  subsystem  on  the  F/A-18.  Significant  improvements  are  foreseen  in  the  area  of  engine 
in-flight  fault  detection  and  isolation  extending  even  to  incipient  fault  detection.  Similar  built-in 
test  improvements  are  envisioned  for  other  "non-avionic"  systems  such  as  environmental  control  system, 
electrical  generating  system,  aircraft  hydraulic  systems,  etc. 

The  avionics  of  the  near  future  must  not  be  of  the  Von  Neumann  school  of  thought  if  the  weapon  capa¬ 
bility  to  life  cycle  cost  ratio  is  to  be  maximized.  The  electronics  of  the  next  generation  weapon  system 
should  stress  dedicated  micro  code  as  opposed  to  general  purpose  microprocessors.  *ach  “^1 

modularized  to  the  electronic  card  level  and  self  tested  to  the  component  level.  When  dedicated  pro 
cessors  are  utilized,  high  level  software  and  its  related  maintenance  is  reduced.  These  application 
directed  architectures  are  gaining  popularity  in  the  commercial  world  as  hardware  -osts  decrease  and 
software  design  and  maintenance  costs  increase. 

Because  the  currently  designed  AFTA  takes  the  place  of  the  Mission  Computers  aboard  the  aircraft, 
it  can  perform  other  non-maintenance  related  tasks.  One  such  area  is  pilot  training.  Presently,  an 
F/A-18  prospective  pilot  spends  significant  training  time  in  an  aircraft  simulator.  After  basic  familiar! 
zation  the  pilot  will  log  flight  hours  in  a  two  seat  T/F-18.  The  AFTA  has  the  capability  to  gene  a 
ITAZs  co^t  scenarios  for  on-the-ground  training  in  the  F/A-18  cockpit.  The  AFTA  can  simulate  various 
air-to-air  or  air-to-ground  missions  by  generating  the  appropriate  weapons  and  radar  displays  and  res- 
^ngto  pilot  actions.  In  this  approach,  the  aircraft  can  be  used  as  a  simulator  whennotrequired  for 
operations  resulting  in  a  reduction  in  total  training  cost  and  an  increase  in  pilot 

type  of  training  need  not  be  limited  to  pilot  operations.  The  maintenance  crew  could  be  trained  using 
s^h  a  device  by  programming  aircraft  fault  indications  and  tutoring  personnel  on  F/A-18  maintenance 

procedures. 

The  AFTA  was  originally  conceived  as  a  suitcase-sized  flight  line  tester.  However,  the  WRA's  could 
be  supported  by  the  AFTA  at  the  intermediate  maintenance  level  if  the  aircraftenvironmentissimulated. 
Such  a  simulator  has  been  conceptually  designed  and  is  anticipated  to  be  comprised  of  a  single  rack  of 
equipment  called  the  Aircraft  Simulator  (AIRSIM) .  The  AIRSIM  and  an  AFTA  are  depicted  in  Figure  15  as 
,  WRA  prescreener.  Due  to  AFTA's  short  test  time,  most  WRA's  can  be  fault  isolated  and  repaired  with°ut 
using  the  Avionics  Test  Set.  Total  I-Level  throughput  may  be  increased  by  an  order  of  magnitude.  The 
AIRSIM  will  be  developed  early  in  1984. 
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FIGURE  15 

l-LEVEL  AFTA  AS  A  WRA  PRESCREENER 


20-13 


REFERENCES : 

1.  Defense  Science  Board,  USA  Secretary  of  Defense,  "Operational  Readiness  with  High  Performance 
Systems,"  April  1982 

2.  Comptroller  General  of  the  United  States,  "Operational  and  Support  Costs  of  the  Navy's  F/A-18  Can 
Be  Substantially  Reduced,"  June  1980,  LCD-80-65. 

3.  Kiesel,  Harvey  K. ,  Support  Equipment  System  Program  Office  Aeronautical  Systems  Division  -  AFSC, 
"BIT/SIT  Improvement  Project  Evaluation  of  Selected  USAF  Aircraft  BIT/SIT  System/Subsystem," 

April  1979,  ASD-TR-79-5013. 

A.  Yoder,  ComeliaM.  and  Schrag,  Merilyn  L. ,  IBM  Corporation,  "Nassi-Shneiderman  Charts,  An  Alternative 
to  Flowcharts  for  Design"  -  November  1978 


ZU-i** 


DISCUSSION 

W.H.Miller, 

(1)  Is  the  AFTA  capable  of  off-loading  the  ATS  and  if  so,  by  how  much? 

(2)  Will  MCAIR  be  marketing  the  AFTA  or  have  marketing  rights  been  sold  to  Australia? 

(3)  What  is  the  ROM  cost  of  AFTA,  particularly  its  software? 

Author’s  Reply 

( 1 )  Depending  on  the  assumed  AFTA  effectiveness  at  I-level,  very  preliminary  studies  indicate  the  ATS  workload 
can  be  decreased  significantly  (as  much  as  30%). 

(2)  AFTA’s  sold  will  be  through  MCAIR,  but  will  be  manufactured  in  Australia. 

(3)  The  answer  might  be  had  through  formal  means  via  MCAIR. 

R.  Davies,  Ca 

With  respect  to  the  Avionic  Fault  Tree  Analyser  (AFTA)  equipment  -  a  3-part  organizational  question  prompted  by 
the  thought  that  organizational  considerations  sometimes  impede  technological  progress:— 

( 1 )  Does  the  AFTA  replace  a  T.O.  (Tech.  Order)? 

(2)  How  does  the  maintenance  man’s  supervisor  fulfil  his  responsibilities? 

(3)  For  the  Canadian  Forces,  how  does  an  unilingual  French  speaking  technician  get  a  simultaneous  translation  of 
an  English  language  AFTA? 

Author’s  Reply 

( 1 )  No.  The  AFTA  refers  to  the  T.O.’s  in  its  instructions  to  the  maintainer. 

(2)  The  maintenance  supervisor  will  make  the  same  decision  with  or  without  an  AFTA. 

(3)  The  plasma  display  doesn’t  care  what  language  is  appearing  on  it.  It  can  easily  be  translated. 


J.F  .Irwin,  US 

( 1 )  Has  the  avionic  BIT  been  adequate  to  allow  for  minimum  ambiguity  and  how  was  it  verified? 

(2)  How  much  additional  diagnostic  software  had  to  be  added  to  the  AFTA  to  account  for  poor  system/subsystem 
diagnostics? 

(3)  How  are  problems  associated  with  interface  problems  resolved  if  at  all  with  the  AFTA? 

Author’s  Reply 

(1)  The  current  avionics  BIT  is  not  adequate  to  eliminate  ambiguity  groups;  however,  they  can  be  minimized.  The 
fault  tree  diagnostics  were  verified  by  inserting  faults  into  the  avionics  in  the  lab. 

(2)  As  I  indicated,  the  system/subsystem  avionics  diagnostics  were  designed  for  WRA  fault  isolation.  The  amount 
of  software  added  to  the  AFTA  was  to  extend  the  aircraft  BIT  to  the  SRA  level.  The  fault  tree  program  sizes 
range  from  9  kbytes  to  100  kbytes. 

(3)  Interfaces  between  WRA’s  other  than  the  avionics  MUX  bus  have  been  minimized  in  the  F/A-l 8A  aircraft ; 
however,  when  they  do  exist  leg  discrete  inputs  (i.e.  switches)  of  the  fault  tree  will  require  the  maintainer  to 
toggle  or  exercise  the  appropriate  interface.  If  the  interface  is  between  SRA’s  within  a  WRA  the  fault  tree  will 
go  beyond  WRA  bit  and  perform  memory  inspections  and  functional  testing  of  the  interface.  The  AFTA 
cannot  in  all  cases  eliminate  the  ambiguity  between  the  two  or  more  SRA’s  and  the  interface  media. 


N.I.B.  Young,  UK 

I  was  particularly  interested  in  the  use  of  your  method  to  record  intermittent  faults  as  they  occur  in  flight.  We  had  a 
similar  requirement  and  were  obliged  to  use  EEPROM  technology  for  non-volatile  storage.  We  had  problems  with 
this  technology  since  it  is  low  volume,  very  slow  and  of  limited  life,  and  so  we  had  to  perform  data  reduction  only 
storing  the  first  occurrence  of  each  type  of  fault.  Did  you  encounter  the  same  problems  and  if  so  how  did  you 
overcome  them? 

Author’s  Reply 

At  this  time  the  AFTA  function  is  not  in  the  aircraft.  However,  the  feasibility  mode/ AFTA  uses  BUBBLE  memory 
for  off  line  storage.  All  message  capture  is  stored  in  RAM ;  however,  until  the  BUBBLE  memory  can  be  updated  the 
BUBBLE  memory  is  not  cache  memory,  access  time  is  in  the  order  of  milliseconds.  BUBBLE  memory  has  an 
impressive  MTBF  and  does  not  wear  out  as  rapidly  as  EEPROM  or  Floppy  Disks. 


W.G.MuUey,  US 

(1 )  Other  than  a  printer,  would  an  ECP  for  the  F-18  require  any  other  hardware  changes  or  would  all  changes  be  in 
software? 

(2)  In  second  level  testing,  is  a  different  UUT  interface  necessary  for  each  unit  as  it  was  on  VAST? 

Author’s  Reply 

There  will  be  only  one  interface  drawer  for  the  1 5  priority  WRA’s  to  be  tested  by  the  I-level  AFTA. 

(1 )  The  extent  of  the  ECP  would  depend  on  the  method  used  to  implement  the  AFTA  function.  A  separate  AFTA 
box  would  require  wires  added  (i.e.  power,  MUX,  printer,  interface).  If  the  implementation  is  with  the  mission 
computer,  maintenance  signal  data  recording  system,  and  the  cockpit  displays,  I  would  not  anticipate  hardware 
modifications. 
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1.  INTRODUCTION 

La  maintenance  premier  echelon  a  deux  objectlfs  : 

-  la  localisation  des  URP  (Unites  RemplaqaDles  en  Piste)  en  panne 

-  la  validation  des  chalnes  fonctlonnellea 

qul  dolvent  Etre  atteints,  dans  les  avlons  de  combat  modernes,  en  n'utlllsant  que  des  dlsposltlfs 
embarquEs.  La  maintenance  intEgree  dans  les  systAmes  d'armes  permet  de  rEpondre  a  ces  lmperatlfs  en 
mettant  3  profit  1' Evolution  technologique  des  Equlpements,  1 'architecture  du  SystAme  d'Armes  et  le  bus 
d'Echange  d' Informations  multiplex?  "Dlglbus"  A  gestlon  centralisee,  utilise  en  partlculler  aur  le 
MIRAGE  2000. 

La  maintenance  IntEgrEe  prEsentee  lei  repose  sur  les  princlpes  de  base  sulvants  : 

-  DEveloppement  le  plus  complet  possible  des  autotests  dans  les  Equlpements  quelle  que  solt 
leur  technologle.  Ces  autotests  peuvent  Etre  classes  en  deux  catEgorles  prlnclpales  : 

.  Autotests  non  perturbants,  exEcutes  pendant  le  fonctlonnement  "opEratlonnel"  de  l'Equlpement. 

Les  rEsultats  de  ces  autotests  peuvent  Etre  enreglstrEs  dans  le  calculateur  gErant  du  bus 
pendant  le  vol. 

.  Autoteats  perturbants,  dEclenchEs  par  le  pllote  ou  le  mEcanlclen,  forqant  l'Equlpement  dans  un 
mode  de  fonctlonnement  Incompatible  avec  son  utilisation  "operatlonnelle”  dans  le  systEme 
d'armes. 

-  Mlse  E  profit  de  1 'architecture  du  Systeme  d'Armes  pour  simplifier  les  opEratlons  de  maintenance  par 
rapport  aux  mEthodes  classlques.  En  effet,  les  fonctlons  rEallsEes  par  le  SystSrae  d'Arroes  rEsultent 
rEsultent  de  "chalncs  fonctionnelles"  rSallsant  une  ou  plusleurs  fonctlons  de  transfert  determinEes, 
obtenues  par  : 

.  des  elEments  matErlels  qul  sont  prlnclpalement  des  circuits  d 'entrEes-sortles,  des  liaisons 
fllalres  et  dans  certains  cas  des  traltements  analoglques  sur  les  Informations  EchangEes 

.  des  Elements  loglques  et  de  calcul  (constituent  le  loglclel),  assurant  A  1'lntErleur  d'un 
Equlpement  des  liens  prlvllEglEs  entre  les  entrEes  et  les  sorties  et  rEallsant  alnsl  la  fonctlon 
de  transfert  de  l'Equlpement. 

Pour  que  le  SNA  rempllsse  correctement  son  rSle,  11  faut  que  les  ElEments  matErlels  et  les  ElEments 
loglclels  solent  tous  deux  IntEgres.  Le  prlnclpe  de  maintenance  retenu  conslste  A  effectuer  des 
contrSles  sEparEs  : 

.  d'une  part  des  ElEments  matErlels 
.  d 'autre  part  des  ElEments  loglclels. 

Une  \Erlflcatlon  de  1'lntEgrltE  de  chacun  de  ces  ElEments  conduit  A  vallder  l'ensemble  du  SNA. 

Par  8  ilte  : 

.  la  vErlflcatlon  des  ElEments  loglclels  se  fera  en  contrSlant  par  des  tests  approprlEs  leur 
IntEgrltE,  sans  falre  appel  A  un  dEroulement  "opEratlonnel”  des  programmes. 

.  la  vErlflcatlon  des  ElEments  matErlels  se  fera  en  Implantant  dans  les  Equlpements  (dotEs  en 
temps  normal  d'un  loglclel  opEratlonnel)  des  loglques  partlcullAres  crEant  des  liaisons  aussl 
simples  que  possible  (recoples)  entre  les  entrEes  et  les  sorties  de  ces  Equlpements,  rEdulsant 
alnsl  les  contralntes  llEes  A  la  mlse  en  oeuvre  des  fonctlons  de  transfert  opEratlonnelles. 

-  Utilisation  du  dlglbus  qul  constltue,  pour  1'opErateur,  une  vole  privllEgiEe  de  dialogue,  permettant 
A  partlr  d'une  Interface  unique  (le  Poste  de  Commande  de  Navigation  :  PCN,  par  exemple)  : 

.  la  lecture  des  Informations  de  panne  enreglstrEes  au  cours  du  vol 

.  la  lecture  des  Informations  reques  en  analoglque  par  les  Equlpements  qul,  fonctlonnant  en 
"Instruments  de  mesure"  pendant  les  opEratlons  de  maintenance,  retransmettent  le  rEsultat  en 
nuaErlque  sur  le  Dlglbus 

.  le  posltlonnement  des  sorties  analoglques  des  Equlpements  qul,  fonctlonnant  en  "gEnErateurs" 
pendant  les  opEratlons  de  maintenance,  dEcodent  les  valeurs  transmlses  par  1'opErateur  via  le 
Dlglbus 

.  Is  mlse  en  oeuvre  momentanEe  de  programmes  partlculiers  rEsldents  ou  chargEs  dans  les  Equlpe¬ 
ments  permettant  d'accroltre  la  couverture  des  tests  internes,  et  dont  le  dEroulement  seralt 
Incompatible  avec  le  fonctlonnement  opEratlonnel. 


-  Utilisation  des  visualisations  et  slgnallaations  disponlbles  en  cockpitt  des  tests  declenches  des 
6quiperaents  qui  fournlssent  2  l’op6rateur  dea  noyens  d’ investigation  complementairea. 


La  separation  des  contrSlea  effectues  sur  lea  elements  materiela  et  lea  elements  logiciela,  liee  2 
une  utiliaation  partlculiere  des  raoyens  disponlbles  dana  l’avion  permet,  tout  en  conservant  un 
controle  de  l'ensemble  des  fonctlons  du  SNA,  une  reduction  importante  dea  moyens  2  mettre  en  oeuvre. 

La  maintenance  integree  comprend  deux  parties  : 

-  La  maintenance  a’exerqant  pendant  le  fonctionnement  operationnel  du  SNA,  basee  sur  Sexploitation 
des  resultats  : 

.  oes  autotests  internes  non  perturbants  des  equipements 
.  des  surveillances  du  dialogue  digibus  dea  equipements 
.  des  tests  declenches  pilote. 

L’ensemble  de  ces  resultats  est  traite  au  niveau  systSme  par  un  logiciel  execute  par  le  gerant  du 
digibus  et  denomme  “Comptes  Rendus  de  Maintenance”. 

-  La  maintenance  s'exerqant  pendant  un  mode  de  fonctionnement  particulier  du  SNA  appeie  ''Fonction¬ 
nement  Maintenance  au  Sol".  Ce  mode  qui  ne  permet  pas  le  fonctionnement  operationnel  du  systSme 
d'armes,  et  destine  2  realiser  toutea  les  operations  de  maintenance  compiementalres  aux  autotests 
et  tests  declenches  pilote.  11  est  mis  en  oeuvre  2  partir  d'un  logiciel  resident  dans  le  gerant 
du  diglbus  constitue  princlpaleraent  d'une  trame  d'echange  digibus  partlculldre  et  de  fonctlons 
organisant  le  dialogue  operateur-systSme . 


2  -  MAINTENAB1LITE  DES  EQUIPEMENTS 

Les  syst?mes  d'armes  lntegres  au  moyen  du  digibua  posaedent  la  particularite  d'etre  g£rea  de  faqon 
centralisee  au  moyen  d'un  calculateur  (denomme  "Calculateur  Principal"  ou  "Tactlque").  L'organlsatlon 
des  echangea  eat  done  le  fait  d'un  6quipement  "maitre",  gerant  un  flot  d' informations  clrculant  sur 
un  support  fllalre  unique  (ligne  de  procedure  et  llgne  de  donnees).  Afin  de  minimiser  le  nombre  et 
l’ampleur  dea  equlpementa  de  maintenance  exterleurs  2  l'avion,  il  faut  s'efforcer  a  ce  que  le  moyen 
priviiegie  permettant  les  echanges  d' informations  op6rationnelles  soit  ausai  le  moyen  privilegie 
d'echange  des  informations  et  dea  procedures  de  maintenance. 

La  Societe  AMD-BA  a  edite  un  document  de  specifications  generales  de  nalntenablllte  des  equipements 
permettant  d'homogeneiser  les  procedures  de  maintenance  au  niveau  du  syst?mes  d'armes  et  de  definir 
l’alde  que  chaque  equipement  doit  apporter  2  la  maintenance  globale  de  ce  systdme. 

2.1-  Materlels  numerlques 

Lea  materiela  numerlques  echangent  avec  leurs  equipements  p6ripheriques  par  des  circuits  d’interface, 
des  informations  nombreuses,  et  varieea  quant  2  leur  forme  (digibus,  analoglquea,  discrets  ...)  et 
aont  dotes  d'un  logiciel  complexe,  comportant  un  nombre  important  de  bouclea  de  programme  dependant 
dea  modes  de  fonctionnement  du  Syst2me  d'Armes,  des  conditions  operationnelles,  de  l'etat  des  peri- 
pheriques.  Ila  aont  l'objet  de  contrSles  ci-dessous  : 

-  ContrSle  par  somme  de  contrfile  (check-aum)  du  contenu  raemoire  programme  i 

.  en  tSche  prlncipale  2  l'initialiaation 
.  en  tlche  de  fond  pendant  le  fonctionnement. 

-  ContrSle  de  parite  (lecture  ou  lecture-ecriture)  en  permanence. 

-  ContrDle  de  la  memoire  de  travail  (RAM  ou  RAX) 

.  aolt  2  l'initialiaation  seulement  (en  tlche  prlncipale) 

.  solt  2  1' Initialisation  en  tSche  prlncipale  puia  en  t2che  de  fond 
.  solt  par  test  dSclenchS. 

-  ContrSle  des  unit 6a  de  traltement 

.  en  t2che  prlncipale  2  l'lnltlallsatlon 
.  en  t3che  de  fond  pendant  le  fonctionnement. 

-  ContrSle  du  d6rouleraent  de  programme  par  chlen  de  garde  (Watch-Dog)  raatlrlel  en  permanence. 

-  Contrfile  des  6changes  :  11s  permettent  de  s'assurer  du  bon  fonctionnement  des  circuits  et  dea 
ltgnes  d'ichanges  d'lnformatlons.  Les  prlnclpea  mia  en  oeuvre  diffSrent  sulvant  la  nature  dea 
(changes. 

.  Echange  diglbus  : 

-  Test  de  connexion  permanent  permettant  de  a'assurer  du  bon  fonctionnement  du 
coupleur  standard  de  diglbus  (COS). 

-  Test  conversatlonnel  aur  une  poaltlon  teat-m6raoire,  permanent,  permettant  de 
s'assurer  du  bon  fonctionnement  dea  Ichangea  d ' information  entre  le  processeur  et 
et  son  Interface  digibua 

-  Teat  conversatlonnel  complet,  ex6cut6  pendant  lea  op6rations  de  maintenance 
compKmentalre  au  sol,  et  permettant  la  qualification  exhaustive  du  couplage  au 
diglbus  de  l'6qulpement  (dScodage  d'adreasea  et  contenu  des  Informations). 
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.  Echanges  analoglques  : 

-  Entrees  de  paramStres  :  les  Iquipements  p&riphlriques  glnlreot  des  excltstioos  de 
valeurs  connues,  programmes  par  l'oplrateur  dans  tout  le  domaine  de  variation  et 
destinies  aux  circuits  d'interface  de  l'lquipement  coosidlrl.  Ce  dernier  code  ces 
paramStres  et  les  transmet,  par  digibus,  3  des  moyens  de  lecture  1  la  disposition 
de  l'oplrateur  (Instruments  de  bord).  L'oplrateur  compare  les  valeurs  lues  aux 
valeurs  glnlrles. 

-  Sorties  de  paramStres  :  l'lquipement  reqoit  par  le  digibus,  une  valeur  de  position- 
nement  de  la  sortie  considlrle  (valeur  programmle  par  l'oplrateur  sur  le  PCN). 

Cette  valeur  est  decodee  et  est  exploitable  soit  sur  un  Instrument  ou  le  PCN  (via 
le  digibus),  soit  rebouclle  en  Interne  sur  les  circuits  d'entrle  de  l'lquipement , 
codie,  transraise  par  le  digibus  :  elle  est  alors  exploitle  au  PCN. 

Nota  :  les  contrSles  d'entrles  ou  de  sorties  vlrifient  aussi  l'integrite  des 
clblages  de  liaison  (tant  numeriques  qu ' analoglques) • 

-  Logiciels  d'aide  3  la  maintenance 

Les  contrSles  de  logiciel  ou  des  Ichanges  nlcessitent  un  logiciel  d'aide  3  la  maintenance, 
capable  d 'assurer  lea  nouvelles  fonctions  de  contr31e.  Ce  logiciel  implique  l'existence  : 

-  d'une  trame  d'lchange  correspondant  aux  besoins  particuliers  de  gestion  :  c'est  la  trame 
maintenance  qui  vient  compllter  le  trame  oplrationnelle  ;  elle  rlside  en  permanence  dans 
l'orgsne  de  gestion. 

-  de  programmes  splcifiques  de  dialogue  oplrateur-systlme  par  1' IntermSdiaire  du  PCN  et  de 
la  visualisation  Tete  Basse,  qui  resident  en  permanence  dans  l'organe  de  gestion.  Ces 
programmes  perraettent  en  psrticulier  d ' acceder  3  des  paramStres  circulant  sur  le  digibus 
(non  exploitls  oplrationnellement  par  le  PCN  ou  la  Vlsu  TSte  Basse)  et  d'llaborer  des 
valeurs  calibrees  destinies  aux  Iquipements  connectes  au  diglbus. 

-  de  programmes  d'side  3  la  maintenance  correspondant  aux  difflrents  calculs  et  traitement 
de  maintenance,  tout  particulierement  ceux  de  cootr&le  des  entries  et  des  sorties. 

II  y  a  lieu  de  remarquer  que  les  paramStres  oplrationnels  issus  des  calculs  et  circulsnt  sur  le 
digibus  ne  seront  pas  slgnificatifs  et  par  conslquent  diff icilement  exploltables  par  l'oplrateur. 
Mais  leur  valldit!  dlpendant  de  celle  du  logiciel  et  des  Ichanges,  ces  psrsmStres  "aveugles" 
sont  indirectement  controlls  par  les  oplratlons  de  maintenance  effectules  sur  les  logiciels  et 
les  interfaces. 


2.2  -  Matlrlels  analoglques  ou  3  loglque  cSblle 

De  par  leur  nature,  ces  Iquipements  ne  peuvent  Stre  contrSHs  que  psr  leurs  sutotests  c"/ou  par  des 
excitations  des  entries  3  des  valeurs  connues.  Ces  valeurs  peuvent  Itre  fournies  : 

-  soit  3  partlr  d'une  information  diglbus  dlcodle  (si  l'lquipement  est  connectl  au  digibus  ou  par 
un  Squlpement  "source"  qui,  lul,  est  connectl  au  diglbus). 

-  soit  par  la  mise  en  configuration  "test"  de  l'lquipement 

-  soit  par  des  moyens  extlrleurs  3  l'avion. 

La  lecture  des  informstions  alnsl  glnlrles  psr  les  Iquipements  peut  se  faire  : 

-  sur  les  visualisations  dlsponlbles  en  cockpit 

-  sur  le  PCN  si  l'lquipement  rlcepteur  de  l'information  est  connectl  au  diglbus 

-  sur  les  prises  de  test  de  l'lquipement  ou  de  l'avion  par  un  moyen  specialise. 


2.3  -  Mlthodes  d' intervention 

Les  mlthodes  d'lntervention  different  sulvant  qu'elles  concerneot  un  probllme  de  nature  analogique  ou 
de  nature  numlrique  : 

-  En  analogique,  ces  mlthodes  demeurent  "classlques" 

-  En  numlrique,  il  n'y  a  pas  lieu  de  reproduire  au  sol  l'anomalie  dltectle  en  vol  mais  : 

.  d'une  part,  de  vlrifier  l'intlgritl  du  logiciel  concernl  (si  besoin  est) 

.  d'autre  part,  de  vlrifier  le  fonctionnement  des  chaines  matlrielles  (circuits  analoglques, 
interfaces,  voles  d'lchange  numSrlquea  et  analoglques). 

L'exlcution  de  ces  actions  par  les  oplrateurs  est  rendue  possible  psr  la  mise  3  disposition  de  moyens 
de  dialogue  internes  3  l'avion  (en  psrticulier  l'adaptatlon  du  PCN  et  de  la  visualisation  Ttte  Basse 
3  la  maintenance). 


3  -  COMPTES  RENDUS  DE  MAINTENANCE 

Les  Comptes  Rendus  de  Maintenance  (CRM)  pernettent,  en  exploitant  les  rlaultats  des  autotests  permanents 
non  perturbants  des  Iquipements,  de  connaltre  l'Stat  du  systSme  d'armes.  L'intlrit  de  ce  disposltlf  est 
d'autant  plus  grand  que  le  taux  de  couverture  des  autotests  des  Iquipements  est  llevl.  Le  logiciel  des 
Comptes  Rendus  de  Maintenance  a  deux  modes  de  fonctionnement  : 

-  Lea  Comptes  Rendus  de  Vol  (CRV)  :  c'est  la  mlmorisation  et  la  datation  de  tnus  les  IvSnements 
de  panne  dltectls  par  les  autotests  entre  le  moment  du  dlcollage  et  1' instant  de  l'atterrissage. 
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Ils  permettent  d'obtenir,  au  sol  : 

.  la  visualisation  des  Squipements  ou  des  URP  qui  sont  tombSs  en  panne  pendant  le  vol,  et 
qui  ne  sont  pas  revenus  I  l'Stat  de  Bon  Fonctionnement  au  moment  du  toucher  des  roues 
(atterrissage) . 

•  la  visualisation  de  l'historique  de  vol,  qui  permet  de  connaltre  dans  quel  ordre  et  3 
quelles  dates  (en  temps  de  vol)  les  equipements  sont  passSs  3  l'Stat  de  panne. 

-  Les  Comptes  Rendus  Sol  (CRS)  :  c'est  la  posslbilitS  de  presenter  au  mScanicien  ou  au  pilote 
l'Stat  instantannS  du  syst&ne  d'armes  du  point  de  vue  des  pannes,  avion  au  sol.  II  n'y  a  aucun 
enregistrement  dans  la  memoire  du  gSrant  et  prSsentation  : 

.  soit  des  Squipements  ou  des  URP  er  panne 

.  soit  des  mots  d'information  de  pam'e  de  chacun  des  equipements  suivant  une  selection 
particuliSre 

en  temps  rSel. 

L’exploitation  des  Comptes  Rendus  de  Maintenance  ne  peut  s'eifectuer  qu'au  sol. 


3.1  -  Constitution  des  Comptes  Rendus  de  Maintenance 

Les  Comptes  Rendus  de  Maintenance  comportent  plusieurs  informations  : 

-  un  Mot  d'Etat  et  de  Panne  (MEP) 

-  un  co.'e  Equipement 

-  un  code  de  type  de  panne 

-  un  mot  de  datstion. 

3.1.1  -  Mot  d’Etat  et  de  Panne 

Les  mots  d'Etat  et  de  Panne  (MEP)  sont  constltues  &  partir 

-  des  Mots  de  ValiditS  et  d'Etat  (MVE) 

-  des  mots  de  mode 

-  des  surveillances  exercees  par  le  gSrant  sur  le  dialogue  digibus  des  equipements 

-  des  surveillances  particuliSres. 

.  Mot  de_Val i.di 1 6  e t_d^E tat  (MVE) 

Un  MVE  est  emis  par  chaque  Squipement  connects  au  diglbus. 

Ce  mot  comprend  deux  parties  : 

-  Une  partle  "validitS"  qui  indique  aux  Squipements  utillsateurs  des  informations  genSrees 
sur  le  dlgibus  que  ces  Informations  sont  utilisables  ou  non. 

Cette  partie  du  MVE  n'est  pas  prise  en  compte  pour  1 'elaboration  d'un  Mot  d'Etat  et  de 
Panne  (MEP). 

-  Une  partle  "Stat"  (sous-entendu  de  pannes).  Cette  partie  contient  le  compte  rendu  du 
rSsultat  des  artotests  que  l'Squipement  dSroule  en  permanence  et  eventuellement  un  bit  de 
synthSse  de  panne  par  URP  pour  les  Squipements  multi-URP. 

.  (tot  jle_Modes  (MM) 

Ce  mot  indique  le  mode  dsns  lequel  l'Squipement  fonctionne.  C'est  dans  ce  mot  que  l'on  trouve 
1' information  "Test  en  Cours".  Le  mot  de  mode,  ou  une  partie  de  ce  mot,  est  pris  en  compte  pour 
l'Slaboration  d'un  MEP. 

.  ^u£V£illance_D_igibu8 

Le  dialogue  Digibus  de  tous  les  Squipements  qui  y  sont  connectSs  est  survelllS  par  le  gSrant  du 
systSme  qui  dStermlne  des  pannes  dialogue  Sventuelles. 

•  jhirv^ i 11 an£e£  £a£ticuliS£e£ 

Ces  surveillances  sont  de  deux  ordres  : 

-  Les  Squipements  non  connectSs  au  diglbus  ont  un  certain  nombre  d’autotests  qui  renseignent 
sur  leur  Stat.  Ces  autotests  concourent  1  l'Slsboratlon  d'un  ou  de  plusieurs  discrete  de 
bon  fonctionnement  qui  sont  transmis 

.  soit  vers  le  gSrant  du  systSme 

.  soit  vers  un  Squipement  qui,  rellS  au  Diglbus,  le  transmettra  vers  le  gSrant. 

Le  gSrant  a  done  la  posslbllltS  de  confectlonner  un  MEP  pour  l'Squipement  Smetteur  des 
dlscrets  de  bon  fonctlonriement  en  question. 

-  Les  Squipements  envolent  soit  vers  le  gSrant  soit  vers  d'autres  Squipements  un  certain 
nombre  d' informations  analogiques  ou  Diglbus.  Les  Squipements  rScepteurs  peuvent  faire  des 
tests  de  vralsemblance  sur  les  informations  qu'ils  resolvent,  et  peuvent  done  dSterminer 
des  pannes  sur  les  "Smetteurs". 

Les  rSsultsts  de  ces  surveillances  sont  : 

.  soit  directement  SlaborSs  par  le  gSrant  lorsqu'll  effectue  lui-mSme  ces  contrSles 
.  soit  disponibles  dans  un  Squipement  reliS  su  digibus  qui  les  retransmettra  vers  le 
gSrant 


Le  MEP  est  done  le  rasaemblement  de  toutss  ces  informations  sur  2  mots  de  16  bits  dsns  lesquels 
on  trouve  : 

-  des  bits  qui  donnent  le  rSsultat  des  sutotests  d'un  Squipement 

-  des  bits  qui  donnent  le  rSsultat  des  surveillances  effectuSes  sur  un  Squipement  par  ses 
pSriphSrlques  ou  le  gSrant  du  systSme. 


» 


21-5 


3.1.2  -  Code  Egulpement 

Cheque  gqulpement  falsant  l'objet  d'un  CRV  possSde  un  code  qui  n'a  de  valeur  que  pour  le  ggrant  du 
systSme.  Les  gquipements  sont  alnsi  hierarchises  implicitement  dsns  la  table  des  Comptes  Rendus  de 
Maintenance.  Ce  code  gqulpement  comprend  8  bits. 

3.1.3  -  Code  de  type  de  panne 

4  types  de  panne  peuvent  ?tre  determines.  Le  code  de  type  de  panne  comprend  2  bits. 

£ann£S_d£  £y£e_l  :  Ce  sont  les  pannes  dgterminges  par  les  autotests  des  gquipements,  ou  par  le 
ggrant  sur  leurs  tests  dialogue  digibus.  Ce  type  de  panne  permet  de  considgrer  que  la  maintenance 
est  rgalisee  par  l’gchange  de  l'URP  fautive  sans  qu'il  soit  necessaire  d'effectuer  des  recherches 
complgmentaires. 

Pannes  de  £y£e  2  :  Ce  sont  toutes  les  pannes  autres  que  celles  dgc larges  par  les  gquipements  eux- 
mgmes  par  l’intermgdiaire  de  leurs  autotests  ou  le  ggrant  sur  la  qualitg  du  dialogue  digibus. 

Ce  sont  done  des  pannes  dgtectges  par  les  "surveillances  particuliSres" .  Dans  ce  cas,  il  y  a  peut- 
Stre  lieu  d'effectuer  des  recherches  complgmentaires  avant  de  dgposer  l'URP. 

Pannes  de_  £y£e  0  :  Dans  le  cas  oil  il  y  a  panne  puis  retour  3  bon  fonctionnement,  il  y  a  indication 

de  type  de  panne  0  au  moment  du  retour  3  l'etat  bon  fonctionnement. 

Pannes_d£  ty£e_S  ;  Dans  le  cas  ou  une  URP  a  fait  l'objet  de  dlx  enregistrements  de  panne  pendant 
le  vol,  elle  est  prgsentee  avec  indication  de  type  de  panne  “S"  pour  "SATURANTE",  quel  que  soit  le 

type  de  panne  du  dernier  enregistrement  :  “1",  ”2“  ou  “0". 

3.1.4  -  Mot  de  Datatlon 

En  vol,  cheque  compte  rendu  de  maintenance  est  enregistrg  en  mime  temps  que  l'heure  3  laquelle  la 
panne  correspondante  a  eu  lieu.  Cette  heure  est  exprimge  en  nombre  de  cycles  longs  d’gchange 
Digibus.  Le  LSB  de  ce  mot  a  une  valeur  de  '.60ms  dans  le  cas  du  MIRAGE  2000. 


3.2  -  Constitution  des  Comptes  Rendi s  de  Vol  (CRV) 

Les  Comptes  Rendus  de  Vol  sont  la  agmorisation  des  Comptes  Rendus  de  Maintenance  entre  le  moment  du 
dgcollage  et  le  moment  de  l'atterrissage,  dans  la  mgmoire  du  calculateur  ggrant  le  Digibus.  Cette 
table  est  mgaorisge  dans  une  zone  RAM  ou  RAX  protggge. 

3.2.1  -  Datatlon 

Le  compteur  servant  3  dater  les  CRV  est  mis  3  zgro  une  premiSre  fois  lors  du  passage  sur  la 
position  "Nevigation”  du  Sglecteur  de  Mode  de  Navigation.  Lors  du  dgcollage,  matgrialisg  par 
l'information  “Train  dgtendu"  le  logiciel  des  CRV  doit  enregistrer  la  valeur  de  ce  compteur.  Ceci 
permet  de  connaltre  l'heure  de  dgcollage  par  rapport  au  passage  en  "Navigation”.  Dans  le  mgme 
temps,  ce  compteur  sera  remis  3  zgro  afin  de  pouvolr  dater  les  CRV  par  rapport  au  moment  du 
dgcollage - 

3.2.2  -  Remise  3  zgro  de  la  table  des  CRV 

La  table  dea  CRV  est  remise  3  zgro  lors  de  le  preaiire  information  "train  dgtendu"  consgeutive  3 
la  mise  sous  tension  du  SystSme  d'Armea. 

3.2.3  -  Enregistrement  dea  CRV 

Au  moment  du  dgcollage,  (train  dgtendu)  il  y  a  : 

-  Remise  3  zgro  de  le  teble  des  CRV  (du  vol  prgegdent) 

-  Enregistrement  de  l'heure  de  dgcollage  (par  rapport  au  pessege  en  NAV) 

-  Remise  3  zgro  du  compteur  horaire 

-  Comparelson  dea  MEP  constitugs  dans  le  premier  cycle  long  suivent  le  dgcollage  et  comparaison 
evec  le  profil  "Bon  Fonctionnement"  de  checun  d'eux. 

Enaulte,  il  y  a  constitution  et  mgmorisetion  d'un  CRV  : 

-  lors  du  paaaage  d'un  MEP  de  1’gtat  Bon  Fonctionnement  3  l’gtat  panne 

-  lors  du  paasage  d'un  MEP  d'un  gtat  de  panne  3  un  autre  gtat  de  penne 

-  lors  du  paaaege  d'un  MEP  d'un  gtat  de  penne  3  l'gtet  de  bon  fonctionnement. 

Cheque  MEP  felt  l'objet  d'une  comparelson  per  cycle  long  d'gchenge  (160ms).  La  mgmorisation  des 
CRV  s'errgte  lorsque  le  contact  de  trein  indique  "Sol"  (Trein  gcresg). 

3.2.4  -  Llmltetlona 

-  Un  MEP  donng  ne  peut  It re  enregistrg  que  10  fois  au  maximum  eu  cours  d'un  vol 

-  Le  nombre  totel  de  mgmorisetions  de  CRV  est  limitg  3  128  pour  un  vol. 

3.2.5  -  Voyent  magngtlque 

Tout  enregistrement  dens  le  table  dea  CRV  feit  besculer  un  voyent  magngtlque  sur  le  tebleeu 
mgcanlcien.  L'enregiatrement  de  l'heure  de  dgcollege  ne  felt  pas  basculer  ce  voyent  qui  est 
rgarmable  manuellament  au  sol. 

3.3  -  Constitution  des  Comptes  Rendus  Sol  (CRS) 

Les  Comptes  Rendus  Sol  sont  constitugs  par  une  table  non  sauvegerdle  dans  le  ggrant  du  Digibus. 
Cette  table  est  constitugs  par  les  comptes  rendus  de  maintenance  instantanngs  de  tous  les 
gquipements  du  Systgme  d'Armea. 

Dans  le  CRS  : 

-  La  datatlon  est  forege  3  zgro 

-  Il  n'existe  pas  de  panne  de  type  "SATURANTE". 
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3.4  -  Procedure  de  visualisation  des  Comptes  Rendus  de  Vol 

La  visualisation  des  Comptes  Rendus  de  Vol  s'effectue  sur  Is  TSte  Basse,  au  sol. 

3.4.1  -  Visualisation  des  pannes  exlstant  d  la  fin  du  vol 

La  liste  des  URP  en  panne  au  moment  de  1 'atterrlssage  est  presentee  en  tete  basse. 

II  apparalt  : 

-  Une  ISre  colonne  de  mngmoniques  de  couleur  verte,  surmontee  du  chiffre  1  trace  en  vert. 

Les  mngmoniques  de  cette  colonne  correspondent  aux  URP  en  panne  de  type  1. 

-  Une  2gme  colonne  de  mngmoniques  de  couleur  ambre,  surmontee  d'un  2  ambre. 

Ces  mngmoniques  lndlquent  les  URP  en  panne  de  type  2. 

-  Une  35me  colonne  de  mngmoniques  de  couleur  rouge  surmontee  d'un  S  rouge. 

Ces  mngmoniques  lndlquent  les  URP  en  panne  saturante  (type  S). 

Chaque  colonne  comporte  au  plus  16  mnemoniques.  Lorsque  le  ggrant  demsnde  la  visualisation  de  plus 
de  16  mngmoniques  dans  une  colonne,  la  tgte  basse  ne  visualise  que  les  16  premiers  et  presente  un 
astgrisque  en  has  de  colonne.  L'opgrateur  doit  alors  se  reporter  J  l'historique  de  vol  pour 
connaltre  la  liste  complete  des  URP  ou  equ'pements  en  panne. 

SI  aucune  URP  ou  equlpement  n'est  en  panne,  seuls  apparalssent  le  1  vert,  le  2  ambre  et  le  S  rouge. 
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3.4.2  -  Visualisation  de  l'historique  de  vol 

L'historique  de  vol  est  constltu*  par  l'ensemble  des  CRV  qul  ont  gtg  enreglatrga  pendant  le  vol, 
dans  l'ordre  chronologlque  de  leur  memorisation.  II  est  prgsentg  en  tgte  basse. 

Dans  ce  mode  de  visualisation  le  premier  afflchage  est  celul  du  nombre  de  mgmorlaatlons  de  CRV 
ef fectuges  en  vol,  sulvl  de  l'heure  de  dgcollage  exprimge  en  heures,  minutes,  secondes, 
dlxlfemes  de  seconde. 

Le  second  afflchage  est  celul  du  ler  CRV  enreglstrg,  sous  la  forme  de  4  llgnes  superposges  : 

-  La  premiere  llgne  lndlque  le  numgro  d'ordre  du  CRV,  l'gquipement  concerng  et  le  type  de 
panne  (0,  1,  2  ou  S) 

-  La  seconde  llgne  lndlque  l'heure  de  memorisation  en  heures,  minutes,  secondes,  dixiJmes  de 
seconde. 

-  Les  3e  et  4e  llgnes  de  '■>  csractdres  chacune  reprodulsent  le  MEP  correspondent.  Pour  tout 
bit  1  1  dans  le  MEP  on  visualise  un  point  et  pour  tout  bit  1  0  (c'est-4-dlre  signlflcatif  de 
panne),  le  rang  du  bit  dans  le  mot  du  MEP. 

On  peut  ensulte  dJrouler  tous  les  CRV  d'un  vol  dans  le  sens  croissant  ou  dgcroissant. 


f 
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L'heure  de  decollage  est  toujours  presentSe  3  l'appel  de  la  procedure. 

SI  aucunc  iuSnorlaation  de  CRV  n'a  eu  lieu  en  cours  de  vol,  11  y  aura  su  molns  l'heure  de  d£collage 
Inscrlte  sur  la  tSte  basse. 
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3.5  -  Proctdurc  de  visualisation  deg  Comptea  Rendus  Sol 

Les  Cooptes  Rendus  Sol  ont  pour  but  de  presenter  l'fitat  lnatantann?  du  systime  du  point  de  vue  des 
pannes.  La  visualisation  s'effectue  sur  la  T*te  Basse,  au  sol. 

3.5.1  -  Visualisation  des  Equlpementa  en  panne  actuelle 

La  Hate  des  URP  en  panne  actuelle  est  prCsentte  sur  la  TRte  Basse. 

La  visualisation  pr£sent£e  est  seablable  1  la  llste  des  URP  en  panne  des  Conptes  Rendus  de  Vol. 
La  colonne  des  pannes  saturantea  eat  vide  car  une  panne  actuelle  ne  peut  pas  Rtre  saturante. 
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5.2  -  Visualisation  de  l'itat  actuel  d’un  EquipemenC 

L’§tat  actuel  d'une  URP  est  present?  sur  la  T6te  Basse. 

Pour  vlsuallser  l'Stat  actuel  d’une  URP,  on  frappe  au  PCN  un  norobre  de  2  chiffres,  qul  est  le 
numero  dlctionnalre  de  l'Squlpement  auquel  l'URP  est  rattachie.  Apparalt  alors  en  tSte  basse  un 
Compte  Rendu  Sol  sous  forme  d'un  ensemble  de  4  llgnes. 

.  lire  llgne  :  numSro  de  l'iqulpement ,  non  de  1 'gqulpement ,  type  de  panne  (1,  2,  0) 

.  2e  llgne  :  date,  forcie  a  0 

.  3e  et  4e  llgnes  :  HEP  de  l'Squipement,  presence  comme  en  visualisation  de  l'hlstorlque  de 
vol. 

La  frappe  d'un  autre  numiro  fait  apparaltre  le  Compte  Rendu  Sol  correspondant  en  lieu  et  place 
du  prScSdent. 
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6  -  Panne  d'un  iqulpement  utlllsi  pour  les  Comptes  Rendus  de  Maintenance 

En  caa  de  panne  du  i.alculateur  girant,  celle-ci  est  Indlquie  par  les  visualisations  opiratlonnelles. 
Les  mimorisatlons  de  CRV  dtjl  effectuies  sont  perdues.  Aucun  nouveau  traltement  ne  peut  itre  effectu? 
et  11  eat  done  Impossible  de  presenter  un  compte  rendu  quelconque.  En  visualisation  de  Compte  Rendu 
de  Maintenance,  le  girant  secours  provoquera  la  visualisation  des  rCtlcules  1,  2  ou  S  avec  le 
mnimonlque  CP  en  colonne  1. 

En  ce  qul  concerne  les  sutres  Squlpements  nfcessalres  1  la  visualisation  des  comptes  rendus  de 
maintenance,  les  pannes  Iventuelles  seront  dJtecttes  par  les  autotests  declenches,  plus  performants 
que  les  autotests  permanents. 


-  MAINTENANCE  COMPLKHENTAIRE  AU  SOL 


Les  autotests  permanents  des  Cqulpements  et  du  systeme  ont  une  certaine  11ml te  du  fait  qu’lls  dolvent 
ae  dCrouler  sans  perturber  le  fonctlonnement  operatlonnel.  11  s'en  suit  que  la  profondeur  des  tests 
n'est  pas  toujours  sufflsante  pour  ditecter  et  localiser  les  pannes  avec  la  performance  attendue  d'un 
premier  echelon. 

La  maintenance  complements! re  au  sol  dolt  done  permettre  de  compliter  les  autotests  permanents  en 
rendant  possible  la  verification  de  tous  lea  elements  qul  ne  peuvent  l’itre  qu'en  perturbant  le 
fonctlonnement  operatlonnel  du  systime  d'armes.  Les  prlnclpales  fonctions  1  assurer  sont  les  sulvantes 

-  Validation  des  transmissions  d' Informations  analogtques  entre  les  diffirents  equlpements  et  avec 
les  armes. 

-  Permettre  des  tests  plus  profonds  dsns  les  equlpements  en  utlllsant  des  tests  declenches  spicifl- 

ques  dont  les  slgorlthmes  sont  soit  residents  dans  les  equlpements,  solt  "chargeable*"  i  partlr 

d'une  mCmolre  de  masse. 

-  Qualification  exhaustive  du  dialogue  digibus  des  equlpements. 

L'executlon  de  ces  dlffirentes  fonctions  est  rendue  possible  par  les  loglciels  d'alde  i  la  mainte¬ 
nance  sol.  Ces  loglciels  sont  rCpartls  en  deux  groupes  : 

-  Les  loglciels  de  base 

-  Les  loglciels  compiemantaires. 

1  -  Loglciels  de  base 

Ces  loglciels  permanent  de  donner  au  mCcanlcien  tous  les  moyens  de  dlaloguer  avec  le  systime  afln 
qu'll  pulsse  maner  i  blen  toutes  les  operations  de  verification  qul  lul  semblent  nicessalres  afln 
de  localiser  une  panne  ou  de  vallder  une  chalne  fonctlonnelle. 


21-9 


4.1.1  -  Loglclel  Trane  Sol 

En  configuration  maintenance  au  aol,  le  systSme  fonctionne  suivant  un  mode  particulier. 

11  faut  considSrer  deux  types  d’Squipements  : 

-  Les  equipements  analogiques  pour  lesquels  les  operations  de  maintenance  ne  peuvent  se  faire 
qu'en  utilisant  le  aode  de  fonctionnement  operationnel  et  en  simulant  3  1 'entree  un  ensemble 
de  paramStres  cohSrents, 

-  Les  equipements  programmes  num£rlques  pour  lesquels  le  fonctionnement  maintenance  est 
particulier,  le  programme  op£rationnel  est  arrit€  au  profit  d'un  programme  permettant  : 

.  de  posltionner  dlrectement  3  une  valeur  donnee  par  le  Digibus  les  differents  parametres 
de  sortie  analogiques  (hors  Digibus). 

.  de  coder  sur  le  Digibus  la  valeur  de  toutes  les  entrees  analogiques 

.  d'accuellllr  dans  leur  m£moire  RAM  et  d'ex£cuter  des  loglclels  charges  3  partir  du  Digibus 
.  de  d£rouler,  3  partir  d'un  ordre  donn£  par  le  Digibus,  des  tests  Internes  compl£mentaires. 

Les  valeurs  de  positionnement  des  paramStres  de  sortie  analogiques  sont  dellvr£es  3  l'aide  de  Codes 
de  Donn£es  Maintenance  de  Positionnement  (CDMP). 

Les  valeurs  des  paramStres  analogiques  d’entr£e  sont  donn£es  dans  les  Codes  de  Donn£es  Maintenance 
de  Lecture  (CDML). 

Le  d£clenchement  ues  logiciels  de  test  charges  et  des  tests  compiementaires  s’effectue  3  l'aide  des 
Codes  de  Donn£es  Maintenance  de  D£clenchement  (CDMD). 

La  trame  sol  est  done  le  support  de  la  transmission  des  informations  n£cessaires  3  la  realisation 
des  fonctions  d£crites  ci-dessus. 

La  trame  sol  comprend  : 

-  Tous  les  messages  emis  sur  Digibus  en  trame  op£ratlonnelle  mais  dont  la  cadence  est  r£duite 

3  une  fols  par  cycle  long  et  dont  le  contenu  n'est  pas  slgniflcatlf  ;  cecl  d'une  part  pour  ne 
pas  avoir  une  trame  d'£change  trop  complexe  et  trop  chargee  3  gbrer,  et  d'autre  part,  pour  ne 

pas  avoir  une  charge  de  calcul  trop  lmportante  au  niveau  du  g£rant  du  digibus.  Cependant, 

un  certain  nombre  d'£quipements  demandent  que  quelques  echanges  s'effectuent  au  "rythme 
operationnel"  sfln  de  pouvoir  conserver  un  fonctionnement  maintenance  correct. 

-  Les  messages  permettant  de  valider  les  chaines  analogiques,  c'est-3-dlre  les  CDMP  et  CDML 

-  Les  messages  permettant  de  charger  dans  les  £quipements  des  loglclels  de  test 

-  Les  messages  permettant  de  d£clencher  des  tests  coapl£mentalres  charges  ou  residents  (CDMD) 

-  Les  messages  permettant  de  lire  et/ou  d'Ccrire  dans  la  memo ire  du  g£rant  ou  des  £qulpements 

-  Les  messages  de  visualisetion  maintenance  sur  le  PCN  et  la  TSte  Basse. 

4.1.2  -  Loglclel  de  Dialogue  Systime 

La  gestion  des  CDMP,  CDML,  CDMD  est  faite  par  le  m£csnlclen.  Lors  du  passage  de  la  trame  op£ratlon- 
nelle  3  la  trame  maintenance  sol,  les  valeurs  des  CDMP  sont  telles  qu'elles  d£finissent  un  etst 
initial  maintenance  pour  le  systfeme  ;  a  priori,  toutes  les  valeurs  sont  posltlonn£es  3  zero.  Les 
CDMD  sont  toutes  posltlonn£es  3  zero.  Le  loglclel  de  dlelogue  permet  au  m£cenlclen  : 

-  de  posltionner  les  peramfetres  enaloglques  3  une  veleur  choisle  par  lul, 

-  de  lire  les  valeurs  des  paraaitres  enelogiques  cholsls  par  lul 

-  de  dCdencher  les  tests  compiementaires  3  son  lnltletlve. 

L'orgene  de  dlelogue  utilise  est  le  Poste  de  Commande  de  Nevlgetlon  (PCN)  qul  posside  toutes  les 
commandes  n£cessalres,  elnsl  que  les  elements  de  visualisetion  lndlspensebles.  La  ttte  basse  est 
utillsee  comme  bloc-notes,  c'est-3-dlre  qu'elle  permet  de  conserver  l'afflchege  des  huit  derniires 
op£retions  effectu£es  au  PCN. 

De  plus,  ce  loglclel  permet  de  donner  au  mecenlclen  toutes  les  informetlons  necessalres  pour 
surveiller  le  fonctionnement  maintenance  du  systtme  d'ermes. 

4.1.3  -  Cestlon  des  loglclels  compiementelres 

Les  loglclels  compieoenteires  sont  cherg£s  soit  dens  le  g£rant  soil,  dans  les  £qulpements  3  partir 
d'une  procedure  d£finle  psr  ce  loglclel  de  gestion.  Les  logiciels  3  executer  sont  contenus  dens  un 
support  informatique  interne  ou  externe  1  l'avlon  et  connect£  eu  digibus.  Ce  loglclel  de 
gestion  ne  concerne  que  le  chergement  des  logiciels  3  ex£cuter.  L'exploitetlon  des  r£sultets  des 
treltesents  effectu£s  per  les  logiciels  charges  est  essur£e  par  le  loglclel  de  dialogue  systems . 

4.1.4  -  Gestion  de  I'outllleie  sol 

Ce  programme  de  gestion  permet  le  dlelogue  evec  un  £quipeeent  eu  sol  connecte  eu  digibus. 

II  rend  possible  : 

-  La  lecture  de  tout  ou  partie  de  le  m£molre  d'un  £qulpement  par  un  outlllege  sol 

-  L'tcrlture  en  mdaolre  dens  les  £qulpements. 


4.2  -  Loglclels  Compiementaires 

Les  loglclels  compiementaires  sont  contenus  dans  un  tqulpement  interne  ou  externe  eu  systime  et 
chargts  dans  les  equipements  3  l'aide  du  programme  de  gestion  des  loglclels  compiementaires. 

Us  se  dlvlsent  en  deux  groupas  : 

4.2.1  -  Loglclels  compiementaires  de  test  systtme 

Ces  loglclels  sont  chargCs  st  exCcutCs  dans  le  CP  et  ont  pour  but  d'executer  un  test  particulier 
s'adreasanc  3  tout  ou  partie  des  Cquipements  du  Systems  d'Araes.  Ainsl,  le  loglclel  de  Test 
Conversatiouoel  Ccsplet  (TC.C)  permet  de  qualifier  3  cent  pour  cent  la  qualltd  du  dialogue  digibus 
ds  tous  les  equipements  du  systems  d'armas. 
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4.2.2  -  Loglclels  c (implement alres  de  test  equlpement  » 

Ces  loglclels  so'.t  charges  et  executEs  dans  lea  Equipements  y  caaprls  le  gerant.  Ils  sont  executes 
en  Interne  dsns  les  Equlpementa  concernEs  et  ne  s'adressent  en  aucune  fsgon  3  un  de  leurs  pEripheri- 
ques.  * 

Ils  peuvent  Etre  considEres  c offline  des  sutotests  Internes  complEmentslres. 

Nots  :  II  faut  blen  renarquer  que  la  maintenance  IntEgrEe  ne  conslste  pss  3  rechercher  une  panne 
par  un  processus  automatique  sals  3  donner  su  mEcanlr.len  tous  les  outlls  nEcessaires  a  la 
condulte  d'un  dEpannage  ou  3  la  validation  d'une  chalne  fonctionnelle.  » 


4.3  -  Mlse  en  oeuvre  des  Loglclels  de  base  d'Alde  3  Is  Maintenance  Sol 

Le  8y8t3me  d'srmes  ne  peut  passer  en  configuration  maintenance  qu'3  partlr  du  fonctionnement 
opErstionnel. 

L'svlon  Etant  sous  tension,  le  pssssge  de  la  configuration  opErationnelle  3  Is  configuration 
maintenance  ne  peut  s'effectuer  que  si  : 

Les  conditions  de  sEcurlt£  armement  sont  rEunies 

-  Le  train  est  vEroulllE  bas 

-  Le  commutateur  secondalre  du  PSM  est  sur  la  position  "MAINT" 

-  Le  mEcanlcien  a  frsppE  au  clsvier  du  PCN  le  code  de  demande  "Trsme  Sol". 

A  la  reception  de  ce  code  psr  le  gerant,  celul-cl  Emet,  en  trame  opErstlonnelle  et  une  seule  fols, 
un  code  d'ordre  de  commutation  en  fonctionnement  maintenance  des  Equlpementa.  Ensulte,  11  y  s  un 
silence  Digibus  de  2  cycles  longs  pour  permettre  1' Initialisation  des  equlpements  en  fonctionnement 
maintenance  puls  Emission  de  la  trsme  maintenance  proprement  dlte. 

Le  passage  de  la  configuration  maintenance  a  la  configuration  opErationnelle  du  syst3me  d'srmes 
s'effectue  par  : 

-  la  mlse  sur  une  autre  position  que  “MAINT"  du  rotacteur  secondsire  du  ~PSM" 

-  la  mlse  hors  tension  puls  sous  tension  du  systime  d'srmes- 


5  -  CONCLUSION 

Le  prlncipe  de  maintenance  IntEgrEe  dficrlt  let,  a  EtE  EtudlE  de  telle  sorte  que  los  dlspositlfs 
de  malntenabllitS  reprEsentent  un  pourcentage  falble  des  matErlel  et  logldel  des  Equlpementa. 

Au  niveau  ays time,  le  loglciel  reprfsente  environ  25kmots  de  programmes  residents  pour  un  avion 
comme  le  MIRAGE  2000. 

Les  avantages  de  cette  maintenance  IntEgrEe  sont  multiples  : 

-  Grande  Independence  par  rapport  aux  Evolutions  des  loglclels  Equlpements 

-  Recherche  de  panne  sans  simulation  des  conditions  de  vol 

-  Mlse  en  oeuvre  sans  utilisation  de  moyens  de  test  extErieurs  3  1' avion  sauf  en  ce  qul 
concerne  les  capteurs  et  certains  circuits  d'armement 

-  Exploitation  sur  avion  des  rEsultats  avec  posslbllltE  d' avoir  une  bonne  connalssance  de 
la  nature  et  de  la  durEe  des  pannes  qul  se  sont  produites  en  vol  et  qul  ne  sont  pas 
tou jours  dEcelables  au  sol. 

-  Mlse  en  oeuvre  quaslnent  instantann£e  des  loglclels  permettant  les  recherches  de  pannes, 
ou  les  validations  de  chaines  fonctionnelles  du  Systime  d'Armes. 

-  Grande  souplesse  dans  les  procEdures  3  utlliser  pour  effectuer  un  dEpannage,  le  mEcanicien 
utllisant  au  mleux  et  3  sa  seule  Initiative,  les  disp< iltifs  dEveloppEs  dans  le  Systime. 
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SUMMARY 


^This  paper  describes  a  comprehensive  computer-aided  system  for  the  prediction 
of  the  potential  interaction  between  avionics  systems,  with  special  emDhasis 
on  antenna-to-antenna  coupling,  mhe  methodology  is  applicable  throughout  the  life 
cycle  of  an  avionic/weapon  system,  including  system  upgrades  and  retrofits.  As  soon  as 
aircraft  geometry  and  preliminary  systems  information  becomes  available,  the  computer 
codes  can  be  used  to  selectively  display  proposed  antenna  locations,  emittor/receptor 
response  characteristics,  electromagnetic  interference  (EMI)  margins  and  the  actual  ray- 
optical  paths  of  maximum  antenna-antenna  coupling  for  each  potential  interacting  antenna 
''Set.  The  visibility  of  the  entire  interaction  matrix  produces  an  appreciation  and  aware¬ 
ness  that  had  heretofore  been  unavailable.  Antennas  can  be  interactively  relocated  by 
track-ball  (or  joystick)  and  the  analysis  repeated  at  will  for  optimization  or  install¬ 
ation  design  study  purposes.  The  codes  can  significantly  simplify  the  task  of  the 
designer/analyst  in  effectively  identifying  critical  interactions  among  an  overwhelming 
large  set  of  potential  ones.  In  addition,  it  is  an  excellent  design,  development  and 
analysis  tool  which  simultaneously  identifies  both  numerically  and  pictorially  the  EMI 
interdependencies  among  subsystems.  ■*? 


EMC  IN  AVIONIC/WEAPON  SYSTEM  INTEGRATION 


(Electromagnetic  Compatibility  continues  to  be  a  vital  but  elusive  component  of 
Aviontc/Weapon  System  Integration.  Many  modern  examples  illustrate  the  need  to  identify 
and  solve  potential  problems  of  electromagnetic  interference  as  early  as  possible  in  the 
development  cycle  of  an  avionic  system  so  that  expensive  modifications  on  production 
configurations  can  be  avoided  or  at  least  minimized.  In  effect,  compatibility  should  bt 
designed  into  the  system.  Such  a  philosophy  is  inherent  in  the  requirements  of  the 
specification  for  avionic  system  compatibility  (MIL-E-6051)  and  that  for  weapon  system 
integration  (MIL-HDBK-335) .  However,  the  implementation  of  this  goal  remains  a  formidable 
task  in  spite  of  recent  computer-aided  analysis  techniques  (Spina) ,  primarily  because  of 
the  large  number  of  the  likely  interactions  that  must  be  analyzed  and  the  mass  of  data 
that  must  be  evaluated. 

Undesired  interactions  can  be  categorized  as  intersystem,  i.e.  self-compatibility 
problems,  or  intrasystem,  i.a.  problems  between  the  different  avionics  subsystems  of  a 
major  weapon  system.  Perhaps  the  most  cohesive  development  of  the  methodology  cf  intra¬ 
system  analysis  is  fostered  by  the  U.S.  Airforce  at  the  Rome  Air  Development  Center  under 
its  Intrasystem  Analysis  Program  (IAP) (Spina) .  Undesired  intrasystem  coupling  mechanisms 
arise  from  antenna-to-antenna,  wire-to-wire,  case-to-case ,  electromagnetic  field  to  wire 
or  case  and  common  mode  coupling.  The  IAP  effort  has  resulted  in  three  major  computer 
codes  for  EMC  analysis  (Spina) : 

IEMCAP  -  Intrasystem  Electromagnetic  Compatibility  Analysis  Program 

GEMACS  -  General  Electromagnetic  Model  for  the  Analysis  of  Complex  Systems 
and  NCAP  -  Nonlinear  Circuit  Analysis  Program 

IEMCAP  has  beer,  intended  to  include  most  of  the  coupling  modes  in  a  comprehensive  intra¬ 
system  EMC  analysis;  GEMACS  is  intended  for  EM  radiation  analysis  and  NCAP  can  be  used  to 
determine  the  nonlinear  transfer  functions  of  electronic  circuits.  Other  EMC  analysis 
tools  (Hodes  and  Widmer)  have  been  developed  for  the  computer-aided  analysis  of  antenna/ 
antenna  coupling.  However,  all  of  these  "batch"  executed  programs  suffer  from  the  inher¬ 
ent  problems  of  this  computer  aided  process  and  the  inherent  problems  of  input  and  output 
data  quality  and  size  that  are  associated  with  the  computer  programs  themselves. 

2.  DATA  MANAGEMENT  AND  INSIGHT 

Experienced  users  of  large  computer  programs  have  come  to  identify  input  data  valid¬ 
ation  as  an  important  and  non-trivial  first  step  in  the  process  of  producing  credible 
results  (Miller) .  Associated  with  this  is  the  need  to  appreciate  the  degree  to  which  the 
input  data  models  the  desired  features  of  the  physical  system  that  is  being  analyzed. 
Continuity  of  analytical  thought  is  difficult  to  maintain  in  depth  while  waiting  to  analyze 
the  output  data  of  a  "batch"  process . 

The  batch  programs  mentioned  above  often  require  a  complex  input  data  set  and  do  not 
have  a  simple  procedure  to  verify  its  correctness.  The  tabulated  output  data,  even 
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though  comprehensive,  forms  a  massive  amount  of  information  that  must  be  methodically 
analyzed  to  identify  critical  EMC  areas.  A  total  overview  and  an  insightful  appreciation 
of  detail  do  not  come  easily  to  this  process.  By  its  nature,  it  requires  considerable 
time,  skill  and  training  of  the  EMC  engineer. 

The  AAPG  computer  program  was  created  with  the  purpose  of  reducing  these  major 
problems  of  EMC  analysis.  It  is  a  menu-driven  interactive  graphics  system  that  responds 
to  the  user's  need  for  data  validation,  by  producing  organized  displays  of  input  data 
and  at  the  same  time  produces  comprehensive  displays  of  the  results  of  the  EMC  analysis 
in  a  fashion  that  deepens  the  user's  insight  into  the  modelling  process.  AAPG  was 
developed  at  Concordia  University,  Montreal ,  Canada  under  the  sponsorship  of  the  Defence 
Research  Establishment  Ottawa  (DREO) .  In  1980,  IITRI  engineers  at  the  U.S.  Department 
uf  Elcoti. Ciuag uetiu  v~o..ipc.tihill\.y  Auaij  bxe  renLtii  under  luoK  incensi vfe 

operational  use  of  AAPG  under  the  sponsorship  of  the  USAF  Rome  Air  Development  Center 
(RADC)  Compatibility  Measurements  Section  and  since  that  time  DREO,  Concordia,  ECAC,  and 
RADC  have  carried  out  joint  development  of  AAPG.  It  is  designed  to  analyze  antenna-to- 
antenna  coupled  electromagnetic  interference  (EMI) .  Details  of  such  an  analysis  have 
been  described  by  Weinstock(5) .  The  quantity  that  is  computed  is  called  the  narrow- 
band  EMI  Margin.  It  is  the  undesired  signal  level  at  the  receiver  in  dB  above  its 
threshold  level.  This  is  computed  from  the  spectral  characteristics  of  each  interacting 
transmitter  and  receiver,  the  gain  patterns,  and  cabling  losses  of  the  two  antennas  invol¬ 
ved  and  the  coupling  loss  in  the  path  between  the  transmitting  and  receiving  antennas. 

For  modern  aircraft  with  many  avionic  systems  with  multiple  antennas  this  value  must  be 
computed  for  each  likely  interacting  antenna  pair. 

A  useful  representation  of  the  ensemble  of  interactions  is  that  described  by  Spina 
(3)  where  the  total  set  of  interactions  is  visualized  as  consisting  of  an  Interference 
Interaction  Sample  Space  matrix  with  interaction  elements  Tj.j  between  ith  transmitter 
and  the  jth  receiver.  Each  of  these  elements  must  be  examined  and  evaluated  in  order  to 
reduce  the  sample  space  to  those  elements  that  are  critical,  i.e.,  where  the  EMI  Margin 
exceeds  preset  values.  It  should  be  useful  for  the  reader  to  visualize  such  a  sample 
fr™"  the  < 1  kU  horn  fiWfT  sr « I *  a r  ?  dlljilagt  t*  If  re 

the  Tfj  elements,  at  the  same  time  producing  an  appreciation  of  the  validity  of  the 
modelling  process . 

3.  STRUCTURE  OF  AAPG 

Two  major  software  modules  form  the  heart  of  the  AAPG  system.  These  arq  shown  in 
Fi^UCb  A  ttite  iV.vt-sHm  S]fS>PT»  arts  on  the  input  data 

fiie  and  accurately  computes  the  antenna-to-antenna  coupled  interference  and  stores  all 
relevant  data  in  a  mass  storage  file  that  is  accessed  by  the  Graphics  Data  Management 
System.  This  latter  system  is  composed  of  four  distinct  sub-modules  for  displaying 
frequency  coincidence  data,  antenna  position,  the  EMI  margin  data,  and  a  template  to  assist 
in  the  re-positioning  of  antennas.  The  GDMS  identifies  itself  with  a  menu  that  lists 
these  modules  as  well  as  a  "HELP"  module  which  provides  execution  information  for  the 
user,  should  he  forget  the  simple  mnemonic  commands  or  available  options.  Each  of  the 
four  modules  has  its  own  menu  of  simple.  oetrnianCfs  in  yrtiditig  a  "WSfit"  -oii-miand  that  ptuducts 
specific  instructions  for  each  module.  Each  of  these  modules  will  be  described.  The 
reader  should  note  how  in  addition  to  output  data  display  the  input  data  can  be  easily 
verified  by  visual  examination.  Hard  copies  of  each  illustration  can  be  accumulated  to 
LOi-iu  a  oomp^ehehSive  analysis  report. 

4.  IDENTIFYING  AND  BOUNDING  THE  T^  ELEMENTS 

An  entry  Tij  in  the  Interference  Interaction  Sample  Space  will  occur  whenever  there 
is  frequency  coincidence  between  a  transmitter  spectral  emission,  be  it  fundamental  or 
harmonic,  and  the  receiver  spectral  response.  The  EMCCS  identifies  these  combinations 
and  the  frequency  ranges  over  which  they  occur.  This  data  is  available  first  in  tabular 
form  that  consists  of  a  listing  of  each  receiver  and  the  corresponding  transmitters  that 
can  produce  frequency  coincidence.  A  typical  entry  is  shown  in  Table  1. 
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Table  1  shows  that  five  transmitters  can  be  expected  to  interact  with  the  first  receiver. 
Each  combination  is  numbered,  i.e.  1.03,  etc.  This  numbering  is  used  to  command  displays 
of  these  combinations  for  more  detailed  examination.  Hence  the  user  will  obtain  a  hard¬ 
copy  of  this  entire  listing  and  use  it  as  a  working  reference  during  an  analysis  session. 
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Where  no  frequency  coincidence  occurs,  the  listing  so  indicates.  Thus  the  emittor/recep- 
tor  interactions  are  identified.  A  listing  of  the  associated  frequency  ranges  can  be 
obtained  if  it  is  of  interest.  No  explicit  appreciation  of  power  level  differences  is 
available  at  this  point.  To  begin  this  power  level  quantization,  plots  of  emittor/receptor 
frequency  coincidences  can  be  obtained.  These  are  superpositions  of  emittor  and  receptor 
spectral  responses  as  shown  in  Figure  2.  The  simple  command  that  produces  them  is  shown 
in  the  lower  right  hand  corner.  Note  these  displays  are  self-contained  and  complete. 

They  represent  plots  of  the  actual  input  data  used  to  characterize  the  systems  and  as  such 
provide  ready  verification  of  their  characteristics .  Hard  copies  of  the  complete  set  can 
provide  a  complete  graphic  record  that  can  be  annotated  as  say  measurement  data  becomes 
available.  The  region  of  frequency  coincidence  is  now  clearly  visible  as  are  the  assoc¬ 
iated  power  level  differences.  A  cursor  mode  is  available  to  provide  more  precise  readout 
of  frequencies  and  power  levels.  It  can  be  seen  that  a  set  of  these  plots  alone  can  be 
a  useful  tool  for  the  planning  of  frequency  combinations  for  ground  and  flight  test  purp¬ 
oses. 

At  this  stage  then,  Tj.j  has  been  bounded  in  frequency  and  power  level  for  narrow- 
band  interaction  between  individual  systems.  To  determine  whether  the  power  level  differ¬ 
ence  can  be  expended  by  propagation  path  coupling  loss  between  associated  antenna  pairs, 
the  geodesic  path  between  the  antennas  on  the  aircraft  model  must  be  computed.  Although 
the  actual  aircraft  model  and  antenna  locations  are  shown  in  later  EMI  margin  displays, 
a  separate  graphics  module  has  been  provided  in  order  to  validate  and  document  the  air¬ 
craft  model,  the  antenna  locations  and  the  antenna  radiation  pattern  characteristics. 

5.  '  ANTENNA  POSITION  DISPLAY 

The  aircraft  model  and  the  location  of  each  of  the  subsystem  antennas  can  be  verified 
in  the  Antenna  Position  module.  Figure  3  illustrates  a  typical  subsystem  display.  The 
lower  right-hand  corner  lists  the  command  that  produces  it.  The  viewing  angle  can  be 
selected  at  will  to  coincide  say  with  that  used  for  aircraft  installation  drawings.  The 
locations  of  the  antennas  for  the  subsystem  are  shown  as  coded  symbols  and  tabulations  of 
coordinates  of  location  allow  easy  verification  with  aircraft  drawing  data.  The  approx¬ 
imate  radiation  pattern  model  that  is  specified  by  the  input  data  can  be  displayed  for 
each  antenna  as  shown  in  Figure  4.  This  display  contains  both  a  tabular  as  well  as  a 
graphic  display  of  all  the  antenna  information  in  the  input  data  set  and  hence  allows 
for  its  easy  verification.  Hard  copies  of  the  complete  set  of  patterns  provide  a  complete 
record  for  later  examination  of  the  degree  of  approximation  that  had  been  used  for  each 
subsystem.  The  EMCCS  module  computes  the  coupling  path  for  all  antenna  pairs  for  which 
frequency  coincidence  occurs.  The  associated  coupling  loss  (Weinstock)  can  consist  of 
free  space,  fuselage  shading  and  edge  diffraction  losses  depending  on  the  trajectory  of 
the  geodesic  path  between  antenna  pairs.  The  EMI  margin  can  then  be  evaluated.  The  user 
can  examine  all  antenna  pair  combinations  or  restrict  his  examination  to  those  combinations 
where  in  a  pre-set  value  of  EMI  margin  is  exceeded.  These  combinations  are  available  as 
a  tabulated  matrix  that  can  be  produced  on  a  line  printer. 

6.  APPRECIATING  THE  EMI  MARGIN  VALUES 

The  more  complete  quantization  of  the  entries,  Ti j ,  in  the  Interference  Interaction 
Sample  Space  comes  about  when  the  actual  EMI  values  are  known.  The  EMI  margin  module 
allows  the  display  of  this  data  for  each  interacting  antenna  pair.  Figure  5  shows  a 
typical  display.  The  upper  left  hand  corner  consists  of  a  tabulation  of  all  the  compon¬ 
ent  values  that  are  used  to  arrive  at  the  EMI  margin  value  for  the  worst-case  frequency 
of  each  transmitter  harmonic.  Central  to  the  display,  however,  is  the  aircraft  model 
with  the  antenna  locations  annotated  and  most  importantly,  the  actual  coupling  path 
between  the  antennas  shown  as  a  distinguishing  dotted  line.  The  lower  right-hand  corner 
tabulates  the  antennas  involved  and  identifies  whether  the  coupling  path  lies  in  the 
direction  of  the  main  beam  or  sidelobe  of  each  antenna.  Note  then  the  degree  of  apprec¬ 
iation  of  the  modelling  process  that  this  display  produces.  It  becomes  natural  to  examine 
how  closely  the  modelling  represents  the  "real  world"  aircraft  installation  once  the  path 
can  be  visualized  and  the  diffraction  point  for  example,  identified.  Should  the  user 
wish  to  have  a  closer  examination  of  the  path  detail,  the  close-up  display  illustrated  in 
Figure  6  is  available.  The  viewing  angle  can  be  changed  at  will  in  all  these  illustrations 
by  simple  mnemonic  commands.  Once  more,  hard  copies  of  each  set  can  provide  a  complete 
record  of  the  analysis  for  later  examination.  As  a  whole,  the  set  of  displays  and  data 
provide  both  an  overview  and  considerable  insight  into  the  interaction  space  elements  that 
had  heretofore  not  been  available.  A  minimum  set  of  ground  and  flight  test  frequencies 
can  now  be  chosen  with  more  confidence  or  design  action  focused  on  critical  combinations. 
Tolerances  on  EMI  margin  values  are  not  easy  to  assign.  Path  loss  values  are  antenna 
location  dependent.  However  a  position  tolerance  study  implies  a  recomputation  of  all 
interacting  combinations  with  a  new  input  data  set  for  each  new  antenna  location.  Within 
AAPG  this  also  can  be  done  in  an  on-line  interactive  mode. 

7.  SHOULD  THE  ANTENNAS  BE  RE-LOCATED? 

The  re-location  of  aircraft  antennas  involves  several  physical  as  well  as  electro¬ 
magnetic  factors  that  can  affect  performance.  Of  course,  relocation  should  never  be 
considered  without  a  thorough  investigation  of  all  these  aspects.  For  purposes  of  EMC 
anaifrflis  Jhfiturvfttt  At  it  tuus  ifts  tuitat  i"  ■tt* '•i  n*  nagfjir^ 

is  position-dependent.  In  many  retrofit  programs  it  is  desirable  to  examine  alternate 
antenna  locations.  The  Antenna  Position  Input  Module  provides  the  capability  to  do  this 
in  a  direct  and  easy  way.  In  this  module,  when  a  specific  subsystem  antenna  is  called 
up,  a  templated  display  results  which  shows  two  calibrated  views  of  the  aircraft  on  which 
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the  present  antenna  position  is  coded.  Its  coordinate  location  is  also  tabulated  at  the 
bottom  of  the  display  as  shown  in  Figure  7.  A  new  antenna  location  can  be  selected  by 
successively  positioning  the  cursor  in  the  desired  location  on  the  two  views.  The  coord¬ 
inates  of  the  new  location  are  immediately  displayed  as  well  as  its  coded  location  on  the 
two  aircraft  views.  The  antenna  can  also  be  repositioned  by  specifying  the  numerical 
values  of  its  new  aircraft  location  (BL,  WL,  FS)  or  by  a  hybrid  combination  of  cursor 
use  and  numerical  entry.  As  soon  as  the  location  is  acknowledged  to  be  correct,  a  new 
page  is  displayed  that  lists  the  angular  limits  of  the  antenna  pattern.  These  can  be 
altered  line-by-line.  Once  more  the  antenna  pattern  can  be  displayed  as  shown  in  Figure 
4.  Once  the  data  is  acknowledged  as  correct  by  the  user  a  new  antenna  input  file  is 
created.  The  user  exits  from  the  GDMS  via  a  "recompute"  mode  and  the  EMCCS  immediately 
begins  the  total  set  of  new  interaction  computations,  which  when  complete,  can  once  more 
be  reexamined  by  the  GDMS  as  described  above.  The  new  EMI  margin  and  path  loss  values 
can  now  be  evaluated.  This  process  can  be  performed  as  often  as  necessary  and  with  as 
many  antennas  as  is  desired,  as  long  as  the  mass  storage  space  is  sufficient  to  hold  the 
output  information  for  each  separate  input  data  set. 

The  flexibility  of  this  system  has  led  to  its  use  not  only  for  tolerance  and  for  trade¬ 
off  analysis  but  also  for  important  new  applications. 

8.  CREATIVE  NEW  APPLICATIONS 

The  most  extensive  and  varied  use  of  AAPG  to-date  has  bee,,  made  at  ECAC  as  described 
by  Hodes  and  Widmer  (6) .  Of  particular  interest  is  its  use  for  Electromagnetic  Radiation 
environment  evaluations  and  definitions.  The  antenna  gain  at  each  receiver  antenna 
location  can  be  specified  numerically  in  such  a  wty  that  the  resultant  AAPG  output  is  of 
power  density  at  the  antenna  location.  This  has  been  used  to  define  the  total  expected 
EMR  environment  at  weapon  stations  by  locating  antennas  at  these  respective  locations. 

Such  a  probing  can  be  carried  out  at  any  location  that  may  be  of  interest  on  or  near  the 
aircraft. 

Although  helicopters  do  not  lend  themselves  to  the  conventional  nose-cone/cylindrical 
fuselage  representation  of  the  computer  model,  some  can  be  approximated  by  cylinder /cone 
geometries  with  the  cone  facing  aft.  By  careful  specification  of  the  antenna  coordinates 
in  order  to  transform  them  into  values  acceptable  to  the  program,  such  helicopter  geomet¬ 
ries  have  indeed  been  analyzed. 

The  most  recent  comparison  of  AAPG  predictions  with  aircraft  test  data  is  that  report¬ 
ed  by  Hodes  and  Widmer  (6) .  For  an  F-14  aircraft,  AAPG  correctly  predicted  149  EMC 
interactions  out  of  a  156  non-trivial  ones.  In  one  of  these  cases,  AAPG  failed  to  predict 
actual  electromagnetic  interference.  This  failure  was  apparently  subsequently  traced  to  an 
incorrectly  specified  interference  threshold  in  the  input  data.  The  other  six  cases  were 
"fail-safe"  predictions,  i.e.,  cases  of  EMI  where  actual  electromagnetic  compatibility 
(EMC)  existed. 

9.  CONCLUSION 

The  power  and  flexibility  of  AAPG's  interactive  analysis  and  display  capabilities 
provide  the  engineer  with  a  rapid  and  straightforward  way  to  carry  out  the  complex  task 
of  EMC  analysis  and  design  in  modern  avionic  systems.  In  addition  to  base-line  EMC 
surveys,  complex  trade-off  analysis  can  be  carried  out  cost  effectively  and  with  new  in¬ 
sight  into  EMI  interactions.  Studies  of  EMR  environment  are  natural  extensions  of  the 
primary  uses  of  AAPG.  EMC  problems  associated  with  the  integration  of  new  systems  into 
existing  platforms  can  be  analyzed  quickly  and  with  a  more  complete  appreciation  of  the 
associated  coupling  factors  between  systems. 
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Fig.  1  Structure  of  AAPG 
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Fig.  2.  Frequency  Coincidence  Display  With  Cursor 
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Fig.  3  Antenna  Position  Display 
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Fig.  6  Closeup  Of  Coupling  Path-Flat-Bottom  A/C  Model 
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Fig.  7  Antenna  Position  Input,  Cursor  Alone 
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DISCUSSION 


D.  Jaeger,  Ge 

(1)  Do  you  have  some  information  about  the  fault  tolerance  of  this  computer  program;  have  you  made  a 
comparison  between  measurement  and  computer  results? 

(2)  Does  your  program  cover  resonant  effects  of  the  structure  which  may  be  of  interest  for  low  frequency  ranges? 
Author’s  Reply 

(1)  The  best  information  we  have  to  date  is  that  produced  by  engineers  at  the  Electromagnetic  Compatibility 
Center  (ECAC)  in  Annapolis,  Md.  This  is  available  in  the  last  reference  quoted  in  the  proceedings  paper. 

(2)  No.  These  are  rag-optical  techniques  and  cannot  deal  with  resonance  effects.  However,  with  moment  method 
techniques  we  have  been  able  to  detect  these. 


SUMMARY  OF  SESSION  III 
SYSTEM  DEVELOPMENT  CONCEPT 

by 

Dr  G.H.Hunt 
Session  Chairman 


From  an  overall  point  of  view,  the  session  can  be  assessed  as  generally  successful,  the  papers  being  well  presented  and 
generating  some  well-informed  discussions  from  the  floor.  Because  of  the  diverse  range  of  topics  covered  within  the 
session,  it  is  difficult  to  draw  any  specific  technical  conclusion.  What,  however,  was  properly  made  clear  is  that  the  closer 
integration  of  avionic  equipments  in  modem  aircraft  requires  that  very  considerable  time,  and  that  resources  should  be 
devoted  to  the  systems  integration  task. 

Paper  23  dealt  with  the  experiments  on  the  human  factors  aspects  of  the  display  system  for  a  television  guided  lock- 
on  missile  for  use  against  ground  targets,  such  as  will  be  employed  by  the  Federal  Republic  of  Germany.  The  work 
involved  encompassed  head-up  displays,  head-down  displays,  and  helmet  mounted  displays. 

Paper  24  outlined  the  software  development  environments  over  the  last  20  years,  using  as  examples  aircraft 
developed  by  British  Aerospace.  The  problems  of  rapid  growth  of  computer  requirements  were  discussed, and  future 
British  Aerospace  activities  to  meet  these  problems  were  detailed. 

Paper  25  described  the  Avionic  Systems  Demonstrator  Rig  at  British  Aerospace.  This  represents  a  complete  aircraft 
system,  linked  to  an  advanced  cockpit,  appropriate  to  the  next  generation  of  tactical  combat  aircraft.  The  object  of  this 
exercise  is  to  gain  the  experience  necessary  to  reduce  the  development  risk  associated  with  ra;  id  advances  in  technology. 

Paper  26  outlined  the  development  of  communications  and  navigation  identification  (CNI)  systems  from  the  original 
concepts  which  were  just  a  collection  of  individual  equipments,  through  to  a  concept  of  an  integrated  CNI  discussed  in 
this  paper,  in  which  several  receiver-transmitters  are  interfaced  with  a  signal  processor.  Such  a  system  can  be  made 
adaptive,  with  reconfiguration  automatically  carried  out  following  failure. 

Paper  27  originated  from  the  premise  that  the  choice  of  a  weapon  system  must  be  determined  by  the  trade-offs 
between  the  effectiveness  of  the  weapons  and  the  vulnerability  of  the  delivering-aircraft  to  ground  forces.  The  paper 
describes  a  computerised  technique  to  assist  in  assessing  the  vulnerability  of  specific  delivery  tactics.  A  digitised  model  of 
real  terrain  is  used,  and,  to  reduce  the  computational  load,  realistic  profiles  are  developed  from  a  series  of  flight  segments. 
Intervisibility  algorithms  are  used  in  assessing  aircraft  vulnerability. 

Colour  cathode  ray  tube  displays  are  now  approaching  the  stage  of  allowing  their  use  in  high  ambient  light  level 
cockpits.  Paper  28  described  and  discussed  current  technology,  i.e.  beam  penetron  and  shadow  mask,  raster  and  stroke 
writing  and  then  continued  with  a  review  of  a  five-phase  programme  of  assessment  and  demonstration  of  advanced 
technology  displays. 

The  assessment  of  the  value  of  complex  systems  is  a  difficult  and  very  important  task.  Paper  29  described  an 
approach,  based  on  weighting  the  individual  attributes  of  the  system.  An  example  of  the  application  of  the  technique  to 
a  complex  avionic  system  for  a  tactical  fighter  aircraft  was  described. 

Paper  30  described  the  research  programme  using  the  F-16  aircraft  to  develop  and  flight-validate  advanced 
technologies  to  improve  fighter  lethality  and  survivability.  The  digital  flight  control  system  is  the  core  technology, 
providing  6-degree  of  freedom  decoupled  aircraft  control,  being  developed  in  the  present  phase  1  activities.  Phase  2  will 
study  automated  manoeuvring  attack,  in  which  the  digital  flight  control  system  will  be  coupled  to  the  fire  control  system. 

Paper  3 1  was  a  wide  ranging  paper,  covering  most  of  the  avionics  and  weapon  management  aspects  of  future  aircraft, 
although  the  main  concentration  was  on  the  weapon.  A  rig  for  integration  and  test  of  weapon  delivery  systems  was 
described.  A  concept  for  future  weapon  delivery  system  was  discussed,  which  included  such  aspects  as  automatic  mainte¬ 
nance  predictions,  GPS/ITDS/IN  navigation  systems,  etc. 

Paper  32  referred  to  a  requirement  to  identify  preferred  software  tools  for  the  in-service  phase  of  Tornado,  for 
support  ik  mujui  manic.  Mills  in  gamral,  «xi  l'w  support  of  ttw  desofipHmi  «td  (Iw  Jrwlupmenl  J  luUU*  rttmO 
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It  was  considered  that  no  completely  satisfactory  tool  existed  at  the  time,  and  hence  to  meet  this  requirement  CADAS 
was  developed.  This  is  a  computer  aided  design  tool,  designed  to  make  maximum  use  of  commercially  available  operating 
systems. 

Paper  33  dealt  with  the  need  to  study  EMC  problems  in  weapon  systems.  The  paper  emphasized  the  need  to 
consider  the  EMC  aspects  from  the  very  beginning  of  a  project,  and  plan  manning  levels,  work  programmes,  etc., 
accordingly.  Often,  the  primary  objectives  of  structural,  mechanical,  and  electrical  design  will  be  in  direct  conflict  with 
good  EMC  practices.  The  management  of  EMC  must  be  undertaken  by  senior  managers,  familiar  with  the  problems.  The 
programme  must  begin  in  the  planning  stage,  proceed  through  analytical  studies  and  evaluation  tests  to  prove  the  design 
concepts,  and  finish  with  the  testing  of  subsystems,  and  later  complete  systems. 

Paper  34,  the  final  paper  of  this  session,  described  a  programme  initiated  in  1 975  aimed  at  providing  guidance  on  how 
to  design  avionic  systems  for  the  1980s.  Design  considerations  included  cost,  reliability,  and  maintainability.  The  work 
led  to  the  building  of  a  demonstration  system  in  a  Cessna  402  twin-engined  general  aviation  aircraft. 
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DISPLAY/CONTROL  CONSIDERATION 
by 

Klaus  Baking 

DORNIER  GmbH,  Avionics  Dep.,  Postfach  1420,  D-7990  Friedrichshafen 
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INTRODUCTION 


The  deployment  of  combat  aircraft  against  stationary  and  mobile  ground  targets  that 
are  protected  by  air  defence,  means  a  very  high  danger  for  man  and  machine.  In  order  to 
eliminate  this  danger,  it  is  planned  to  develop  and  to  employ  weapons  such  as  low  alti¬ 
tude  dispensers  or  terminal-guided  submunition  (e.g.  WASP)  against  armoured  mobile 
targets,  Short-Range-Anti-Radiation-Missiles  (SRARM)  and  MAVERICK  against  stationary  one's. 

For  successful  attacks  against  ground  targets,  the  Federal  Republic  of  Germany 
intends  to  procure  TV-guided  missiles  of  the  type  AN/AGM-65B  MAVERICK.  This  missile  is 
guided  by  a  TV-seeker  head  with  -e£> scene  magnification.  The  weapon  delivery  is  based  on 
LOCK-ON-BEFORE- LAUNCH.  The  time  between  target  recognition  and  launch  is  very  tight,  so  J 
that  the  weapon  aiming  procedure  has  to  be  as  efficient  as  possible,  ^hc  fol-l-owing^describes 
investigations  to  provide  basic  te3t  data  to  assess  different  methods  of  target  acquisition 
and  missile  seeker  aiming  and  ,l«:k-on.  In  addition^ ■ko-thai_?  the  pilot  workload  with  different 
controls  and  displays  wao  to  boyassessed  and  methods  of  reduction  derived.  -F«rthet-to  this«o 

J  Afferent  weapon  information  and  Weapon-Video-Display-Systeras  and  their  advantages  and 
isadvantages  were  investigated.  The  accuracy  and  speed  of  weapon  aiming  should  be  espe¬ 
cially  evaluated. 
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2.  MISSION 


The  following  gives  a  short  description  of  an  air-to-ground  mission  of  an  one-seated 
combat  aircraft  with  a  TV-guided  MAVERICK.  The  ASM's  are  delivered  against  two  classes  of 
targets  s 


-  primary:  stationary  targets 

bridges,  railways,  command  posts,  storage  depots 

-  secondary:  mobile  targets  of  opportunity 

groups  of  tanks,  mobile  AAA 

The  sequence  of  weapon  delivery  is  shown  in  Fig.  1.  This  is: 

1 .  target  recognition  through  HUD 

2.  identification  and  classification 

3.  pointing  the  aircraft  at  the  target 

4.  moving  the  eyes  from  HUD  to  weapon's  display  with  adaption 
and  accomodation 

5.  target  recognition  with  weapon's  display 

6.  changing  of  video-polarity  (if  necessary) 

7.  putting  the  track-gates  onto  the  target 

8.  lock-on-test 

9.  weapon  launch 

10.  egress 

These  tasks  done  by  the  pilot  take  a  time  of  6  seconds  (minimum)  to  12  seconds  (maxi¬ 
mum)  for  the  first  weapon.  The  distance  the  aircraft  has  moved  within  this  time  is  illustra¬ 
ted  with  a  velocity  of  200  m/s  and  300  m/s  respectively.  Fig.  2  shows  the  horizontal  situation 
for  an  attack  against  a  column  of  tanks  protocted  by  ZSU-23-4. 
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Two  special  points  can  be  highlighted.  The  first  marks  the  place  where  the  targets 
have  been  recognized  and  identified  by  the  pilot.  This  range  depends  on  several  parameters 
e.g.  daylight,  meteorological  limitations.  A  good  number  is  4  km/2,2  NM  (sometimes  6  km/ 
3,2  tod) .  Tiii.  jeCwn.i  pi>it.e  is  characterized  by  the  egress  flight  path  to  av_td  the  lethal 
radius  of  the  air  defence  site.  The  figure  shows  a  turn  radius  for  3  g's.  Weapons  can  be 
delivered  within  a  range  limited  by  theses  two  points.  As  seen  from  Fig.  2,  the  range  is 
approximately  1,9  km/1  NM.  This  leaves  the  pilot  9,5  seconds  for  weapon  delivery  when 
flying  ivU  m/ b  or  kta .  Ine  weapon  delivery  takes  a  time  between  1 , 3  seconds  and  8 , 0 
seconds  after  recognition  and  identification. 


3.  DISPLAY  CANDIDATES 


The  remaining  time  should  be  uses  as  well  as  possible.  One  aspect  here  is  the  best 
display  system.  A  raster  display  system  has  to  be  integrated  into  the  cockpit  area  in 
order  to  present  the  weapons  video  signal  to  the  pilot  (Fig.  3) .  Four  different  candidates 
are  available  with  different  capabilities: 

1 .  Panel-Mounted  Head  Down  Display  (HUD) 

2.  Virtual  Image  Display  (VID) 

3.  Raster  Head-Up  Display  (HUD) 

4.  Helmet  Mounted  Display  (HMD)  (not  investigated  in  laborartory  experiments) 

When  integrating  a  HDD  the  cockpit  panel  has  to  be  redesigned  and  exchanged  in  existing 
aircrafts.  On  the  other  hand  this  type  of  display  can  be  used  as  a  multi-function-display. 

Integrating  a  VID  causes  few  problems  especially  in  existing  aircrafts.  One  aspect, 
however,  is  that  a  VID  reduces  the  visual  field. 

The  weapon  aiming  with  a  HUD  raises  problems  concerning  harmonization  between  both 
lines  of  sight  (weapon  and  HUD)  and  problems  concerning  the  pilot's  physiology. 

To  slew  the  seeker  head  with  a  HMD  before  1  eye  leaving  the  other  free  for  external 
viewing  seems  to  be  a  successful  solution.  Problems  concerning  the  different  images  magni¬ 
fications  have  to  be  considered. 


4.  WEAPON  AIMING  WITH  HUD 

The  procedure  to  aim  the  seeker  head  at  the  target  by  using  a  HUD  is  greatly  different 
to  that  used  with  other  displays.  The  visibility  through  the  HUD  is  overlaid  with  the 
weapon  video.  Special  problems  occur  which  are  discussed  below. 

The  target  has  to  be  detected  and  identified  through  the  HUD.  The  view  through  the  HUD 
should  not  be  affected  at  all.  On  the  other  hand  the  TV-video  produced  by  the  seeker  head 
is  displayed  in  raster.  Now  the  pilot's  full  concentration  should  be  directed  to  observe 
the  video  image  and  the  view  to  the  outside  world  should  not  be  possible.  A  reasonable 
compromise  has  to  be  found  between  these  two  extreme  requirements  which  contradict  each 
other. 

The  HUD-comblners  mostly  used  nowadays  consist  of  a  mirror  with  a  typical  transmission 
coefficient  of  approximately  70%.  The  typical  reflectivity  is  approximately  25%  which 
means  that  75%  of  the  brightness  of  the  CRT  is  lost.  The  remaining  optical  system  has  an 
efficiency  factor  of  about  60  -  80%.  So  the  total  transmission  of  light  in  the  optical 
path  of  the  CRT  of  a  conventional  HUD  is  about  15  -  20%.  The  brightness  of  symbols  must 
be  approximately  1600  ftL  to  be  read  in  worst  case  cockpit  conditions.  This  means  that 
the  brightness  of  the  CRT  must  be  8000  -  10700  ftL  according  to  the  above-mentioned  trans¬ 
mission.  Fig.  4  shows  a  comparison  of  transmission  and  reflectivity  between  reflection 
and  detraction  HUD. 

Taking  a  wide  angle  HUD  (WHUD)  th'  brightness  is  about  1200  ftL.  This  is  in  conjunction 
with  a  contrast  ratio  of  1.16  suffici  in  Central  Europe  with  ambient  light  of  approxima¬ 
tely  7500  ftL  on  a  sunny,  light  cloudy  .say. 

Resolution 

Several  investigations  hove  shown  that  the  following  requirements  have  to  be  met  if 
brightness  with  respect  to  ambient  light  is  sufficient: 

-  8  lines-hight  of  symbols  for  recognition  of  alphanumeric  and  geometric  symbols 

-  more  than  10  lines  for  a  90%  identification  of  alphanumeric 

-  more  than  16  lines  for  a  99%  identification  of  geometric  symbols  and  images 
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o  Geometry 

The  fade-in  of  the  weapon's  video  into  HUD  is  possible  with 

-  rectangular 

-  quadratic  or 

-  circular 

formats.  A  quadratic  or  circular  format  is  preferred  in  accordance  with  the  other  cockpit 
displays.  Since  the  video  format  is  square  (i.e.  500  lines  by  £00  columns),  so  the  square 
format  is  therefore  most  appropriate.  On  the  other  hand  the  information  of  most  interest 
is  in  a  circular  area  around  the  center.  For  this  a  circular  format  was  preferred  in  the 
laboratory  examinations. 
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During  ground  attack  the  pilot's  view  is  mostly  below  the  aircraft  datum  line  (ADL). 

The  lines  of  sight  of  the  weapons  are  depressed  of  about  2°  relativ  to  ADL.  The  real 
FOV  (2,5s  x  2,5s)  of  the  missile  is  shown  in  Fig.  5  by  the  small  square.  On  the  other  hand 
the  video  information  should  be  presented  as  large  as  possible  to  relocate  the  target 
as  well  as  possible  (large  square,  dashed) .  From  this  it  becomes  clear  that  there  never 
will  be  agreement  between  the  two  formats.  The  video  image  has  to  be  presented  at  a  loca¬ 
tion  where  an  observation  of  both  target  areas  (actual  through  HUD;  image  in  HUD)  is  un¬ 
disturbed. 

Fig.  6  shows  several  proposals  to  place  the  video  within  the  HUD  area  of  a  conventional 
HUD  and  a  WHUD.  The  loss  of  information  between  quadratic  and  circular  formats  of  approxima- 
20%  is  shown  in  Fig.  7.  Fig.  8  shows  the  locations  of  video  on  a  WHUD.  Only  when  the 
is  located  in  the  center  area  below  the  ADL  the  scales  for  velocity  and  altitude 
can  be  presented  in  addition  to  the  digital  display  format.  So  this  area  is  preferred. 

The  laboratory  examination  furnished  the  following  results: 

-  If  only  a  part  of  the  video  is  presented  (mini-raster)  the  test  pilots  could 
establish  no  correlation  between  view  out  of  the  cockpit  and  the  display  video  image. 

-  When  presenting  the  whole  video  information  in  the  center  area  of  the  HUD  the  test 
pilots  could  relocate  the  targets. 

-  Only  when  the  video  was  very  bright  the  background  did  not  disturb  the  aiming  process. 


5.  LABORATORY  EXPERIMENTS 

The  goal  of  the  laboratory  experiments  was  to  provide  basic  test  data  to  assess  diffe¬ 
rent  methods  of  target  acquisition  and  missile  seeker  aiming  and  lock-on.  Different  weapon 
information  and  weapon-video-display  systems,  their  advantages  and  disadvantages  were  in¬ 
vestigated.  Accuracy  and  speed  of  a  weapon  aiming  was  evaluated. 

For  the  realization  of  the  experiments  flight  trajectories  have  been  produced  in  a 
terrain/flight  simulator  and  with  some  Alpha  Jets  in  real  flight.  The  flight  path  was  fixed 
(autopilot  function:  attitude  hold)  and  could  not  be  modified  by  the  test  pilots.  This 
was  done  in  order  to  eliminate  the  handling  qualities  of  the  aircraft  from  the  aiming  pro¬ 
cedure  and  to  concentrate  the  testpilot's  attention  to  the  displays  and  controls. 

Six  flight  trajectories  were  presented  against  five  tactical  targets: 

1 .  industrial  site 

2.  bridge  over  river  (approach  from  the  hill  side) 

3.  bridge  over  river  (approach  into  a  valley) 

4.  tanks  in  assembly  area 

5.  cluster  of  shelters  on  an  airbase  area 

8.  tanks  for  air  defence  on  an  airbase  area 

The  investigations  have  shown  that  target  No.  1  could  be  detected  very  well  because  of 
their  prominence.  The  targets  No.  2  and  3  were  difficult  to  detect  because  there  was  only 
little  contrast  with  the  surrounding.  Target  No.  4  was  the  most  difficult  one  because  the 
tanks  were  masked.  Targets  No.  5  and  6  were  fairly  easy  to  detect  because  the  shelters  had 
a  clears  structure  and  the  tanks  provided  a  good  contrast 


The  procedure  for  weapon  delivery  was  the  following  (Fig.  9): 

1  Start  the  flight  from  the  top  of  the  pull-up  manoeuvre;  aircraft  pointed  at 
the  target;  dive  angle  -10°;  slant  range  6  km/3.2  NM;  velocity  200  m/s/390  kts 

2  UNCAGE  the  seeker  head  when  the  target  is  recognized  on  the  display 

3  Slewing  the  seeker  head  onto  the  designated  target 

4  Activating  the  lock-on  algorithm 

5  Weapon  release 

6  Next  weapon,  see  2 

The  times  for 

-  target  recognition  (t^ ) 

-  lock-on  (t2) 

-  weapon  launch  (t^*) 

were  recorded  and  interpreted.  In  addition  the  testpilots  had  to  fill  in  a  questionnaire 
to  give  their  personal  opinion  concerning  efficiency  and  workload  with  the  different  displays. 


6.  RESULTS 

In  addition  to  the  subjective  impression  the  objective  criteria  for  valuation  were  ana¬ 
lysed,  like  duration  for  recognition/lock-on/launch  and  the  number  of  weapons  delivered. 

16  testpilots  carried  out  185  approaches  with 

HDD  =  60  /  32% 

VID  =  62  /  34% 

HDD  =  63  /  34% 

From  now  on  all  numbers  are  normalized  to  a  basic  figure.  A  total  number  of  100  missiles  had 
been  "delivered"; 

HDD  =  44% 

VID  =  31% 

HUD  =  25% 

No  missile  could  be  launched  successfully  within  32  approaches.  This  is 

HDD  =  22% 

VID  =  32% 

HUD  =  30% 

One  or  more  missiles  could  be  launched  successfully  with  68  approaches: 

HDD  =  38% 

VID  «  32% 

HUD  =  30% 

Two  or  three  (max.)  missiles  could  be  launched  successfully  with  42  approaches: 

HDD  =  44% 

VID  «  30% 

HUD  =  26% 

Three  missiles  could  be  launched  successfully  with  25  approaches: 


HDD  *  61% 

VID  »  28% 

HUD  «  1 1  % 


Taking  the  average  for  all  types  of  displays  and  all  targets  gives  a  number  of  success¬ 
fully  launched  missiles  with  one  approach 

HOD  *  1,82 

VID  =  1,23 

HUD  =  1,00 

The  absolute  figures  depend  on  several  effects  of  mostly  subjective  nature.  In  order 
to  get  a  better  overview  over  the  results,  the  number  of  missiles  and  the  different  dura¬ 
tions  are  compared  among  each  other.  So,  the  results  for  VID  are  arbitrarily  set  to  1. 

The  frequency  for  the  number  of  delivered  missiles  are  shown  in  Fig.  10  with  this  basis. 
This  proves  the  superiority  of  HDD  with  a  result  of  48%  better  than  VID  and  82%  better 
than  HUD.  The  difference  between  VID  and  HUD  is  not  so  dramatic  (23%). 


The  results  gained  from  the  number  of  missiles  can  be  proved  by  analyzing  the  durations. 
The  average  time  to  recognize  the  target  for  the  first  time  is  (normalized) 


t1 1 (total)  =  1  sec 

This  means  for  the  different  displays 


HDD  = 

0,89 

sec 

VID  = 

0,99 

sec 

HUD  = 

1,14 

sec 

To  recognize  the  target  for  the  second  missile  is 


t.j2  (total) 

= 

0,24 

sec 

HDD 

= 

0,22 

sec 

VID 

= 

0,25 

sec 

HUD 

o 

0,26 

sec 

the  third 

time 

t13 (total) 

= 

0,19 

sec 

HDD 

= 

0,16 

sec 

VID 

s 

0,24 

sec 

HUD 

= 

0,18 

sec 

These  results  make  clear  that  the  time  to  recognize  the  target  the  first  time  is  the 
smallest  for  HDD.  VID  is  approximately  10%  and  HUD  25%  ill  towards  HDD.  VID  and  HUD  are 
fairly  equivalent  for  the  second  recognition.  HUD  is  13%  better. 


The  time  between  recognition  and  launch  is  the  duration  of  weapon  aiming.  It  is 
different  for  the  first,  second  and  third  missile  because  of  the  learning  effects. 


For  the  first  missile  it  took 


t21 (total) 

* 

2,06 

sec 

HDD 

m 

1,69 

sec 

VID 

m 

2,01 

sec 

HUD 

m 

2,48 

sec 

The  time  for  aiming  the  second  missile  is 


^22 

m 

0,94 

sec 

HDD 

m 

0,98 

sec 

VID 

m 

0,82 

sec 

HUD 

m 

1,01 

sec 

In  this  case  VID  is  the  best  one  with  a  saving  of  time  of  19%  towards  HDD  and  22%  towards 
HUD. 

The  time  to  aim  the  third  missile  is  still  smaller. 


t23 (total) 

m 

0,76 

sec 

HDD 

* 

0,68 

sec 

VID 

m 

0,70 

sec 

HUD 

m 

0,90 

sec 

Finally  the  total  time  for  the  delivery  of  the  first  missile  is  considered  (Fig.  11). 
The  average  time  over  all  displays  and  all  approaches  is 

t  (total)  =  3,11  sec 

and  for  the  three  types 

HDD  =  2,62  sec 

VXD  =  3,16  sec 

HUD  =  3,64  sec 

The  overall  saving  of  time  is  17%  towards  VID  and  28%  towards  HUD. 

To  summarize  the  results  Fig.  12  shows  the  three  different  aspects  that  came  into  the 
valuation  for  the  effectiveness  of  a  display  system 

o  number  of  successfully  delivered  missiles 

o  time  (saving  of  time  resp.)  for  weapon  delivery 

o  pilot's  judgements  concerning  effectiveness 

All  three  criteria  indicate  the  same  tendency. 

The  testpilots  gave  the  HDD  the  first  rank.  This  display  scored  the  most  successfully 
delivered  missiles  and  led  to  the  greatest  amount  in  saving  time.  Fig.  13  summarizes  the 
most  important  results. 

Three  facts  can  be  stated  to  comprise  the  results: 

1.  The  superiority  of  the  HDD  is  evident. 

2.  Weapon  aiming  with  a  raster  HUD  is  possible. 

3.  There  is  only  a  little  chance  for  weapon  delivery  of  LOBL-missiles  in 
a  one  seated  combat  aircraft  in  Central  Europe  without  support. 

The  improvement  of  weapon  delivery  results  in  supporting  the  pilot  during 

-  tar gat  recognition  and 

-  weapon  aiming  . 

The  following  outlines  are  subject  to  further  investigations  and  no  results  are 
available  yet. 
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The  launch  range  of  LOBL-missiles  is  restricted  by  the  capabilities  of  human  eyes  because 
the  pilot  has  to  detect,  identify  and  classify  the  target  through  HUD.  The  stand-off  capa¬ 
bility  of  the  weapon  could  be  used  to  increase  the  effectiveness  of  the  attack.  For  this 
the  pilot  has  to  be  supported  by  special  computation  and/or  additional  sensors  with  a 
wide  f ield-of-view  (FOV) .  This  could  either  be  a  FLIR-  or  a  RADAR-System .  Hot  points  can 
be  detected  in  a  FLIR  image.  These  can  be  examined  for  the  presents  of  simple  features 
like  length,  width,  contrast, movement  etc.  / 4 / ,  to  classify  the  targets.  These  targets 
shall  be  marked  in  a  special  manner  (e.g.  flashing).  The  pilot  steers  the  aircraft  so 
that  the  symbol  will  be  within  the  FOV  of  the  missile  displayed  in  the  HUD.  Now  he  is  sure 
to  refind  the  target  on  the  weapon's  display.  The  idea  is  that  although  the  pilot  did  not 
see  the  target  in  the  HUD  -only  the  symbol-  that  he  can  use  the  magnified  image  of  the 
weapon  seeker  head  to  increase  detection  range. 
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A  dramatic  improvement  of  ground  attack  can  be  expected  by  reducing  the  time  for  weapon  ^ 
aiming.  A  reduction  can  be  accomplished  if  not  the  pilot  but  an  intelligent  electronic  slewes 
the  seeker  head  to  bring  the  target  into  the  weapon's  tracking  area.  For  this  purpose  the  ^ 
pilot  designates  the  target  to  be  attacked  on  the  weapons  display  by  pressing  his  finger 
onto  the  target  area  on  the  display.  An  electronic  device  finds  out  where  he  has  pointed. 

Two  angles  (azimuth  and  elevation)  relative  to  the  middle  of  the  display  are  evaluated.  The 
seeker  head  is  now  moved  to  zero  these  two  angles  and  makes  lock-on,  The  pilot  has  to 
examine  whether  the  seeker  has  locked  on  to  the  designated  target. 

The  advantage  of  this  procedure  is  that  the  pilot  looks  into  the  cockpit  to  refind  the  tar¬ 
get  only.  After  designation  he  can  direct  his  attention  to  other  things,  e.g.  to  keep  the 
flight  trajectory  or  observe  the  threat.  Since  nulling  of  the  two  angles  can  be  achieved 
automatically  faster  than  the  pilot  can  do  it  himself  the  time  for  weapon  aiming  will  be 
reduced. 
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LIST  OF  ABBREVIATIONS 

ADL  Aircraft  Datum  Line 

ASM  Air  to  Surface  Missile 

FOV  Field  of  View 

HDD  Head  Down  Display 

HMD  Helmet  Mounted  Display 

HUD  Head  Up  Display 

LOBL  Lock  On  Before  Launch 

SRARM  Short  Range  Anti  Radiation  Missile 

VID  Virtual  Image  Display 

WHUD  Wide  angle  Head  Up  Display 


1.  TARGET  RECOGNITION 

2.  IDENTIFICATION/CLASSIFICATION 

3.  POINTING  A/C  AT  TARGET 


REFLECTION 
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Fig.  11:  MEANVALUE  OF  TOTAL/AIMING-TIME 

NUMBER  DF  SUCCESSFULLY  I  TIME  SAVING 

DELIVERED  MISSILES  PER  DISPLAY  |  HUD  (-0)  IN  SEC 


PILOT’S  JUDGMENT  (EFFECTIVENESS) 
(ID  *  high;  0  *  Tow) 


t.  Pilot's  judgment  about  effectiveness 


HIGH  :  HDD 


MEOIUM  :  VIO 


LOW  :  HUD 


2.  Number  of  successfully  “delivered"  missiles 


Number  of  missiles 
in  1  attack 


No  missiles  delivered 


1  or  more  missiles 


2  or  more  missiles 


3  missiles 


H00 


VIO 


1.82 

13 


1.23 


22 


47 


40 


34 


28 


28 


3.  Ouration 


for  relocation 

H00 

VID 

1.  missile 

3.06 

3 .40 

2.  missile 

0.75 

0.86 

3.  missile 

0.56 

0.82 

aiming  time 

1.  missile 

5.79 

6.87 

2.  missile 

3.35 

2.82 

3.  missile 

2.34 

2.4 

total  time  for  1  missile 


8.79 


10.82 
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DISCUSSION 


G.Hunt,  UK 

Are  the  performance  advantages  shown  for  the  Head-Up  Display  expected  to  be  valid  in  a  more  realistic  experiment 
in  which  vibration  was  present  and  the  pilot  was  performing  a  real  flying  task? 

Author’s  Reply 

Also  in  real  flight  tests  we  expect  that  weapon  aiming  will  be  possible  with  HUD.  But  some  problems  have  to  be 
solved,  especially  concerning  (1 )  brightness  of  the  video  image;  (2)  pilot’s  training  to  overcome  physiological 
burdens. 


W.H.Vogl,  Ge 

The  method  that  the  pilot  selects  his  target  with  the  fingertip  at  the  display  surface,  sounds  certainly  attractive.  Did 
you  investigate  whether  the  pilot  will  be  able  to  bring  his  finger  sufficiently  close  to  the  target  point,  under  dynamic 
high  g-load  conditions  in  the  cockpit  as  they  might  occur  in  TF  manoeuvring/target  approach?  Can  you  provide  us 
with  results  of  such  investigations? 

Author’s  Reply 

For  precise  weapon  aiming  and  lock-on  of  Lock -on-before-launch-weapon  in  air-to-ground  engagement  the  pilot  has 
to  leave  TF-flight,  pop  up  and  dive  to  the  target.  On  this  dive  there  won’t  be  great  g-manoeuvres. 
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CASCADE  :  A  DESIGN  ENVIRONMENT  FOR  FUTURE  AVIONIC  SYSTEMS 

- . by 

A.  0.  Ward 

British  Aerospace  PLC 
Warton  Division 
Warton  Aerodrome 
PRESTON 
PR4  1  AX 


SUMMARY 


^Current  trends  in  computing  hardware  technology  are  leading  to  a  dramatic  increase  in 
the  processing  capability  of  avionic  systems.  ,  When  viewed  in  parallel  with  international 
efforts  to  standardise  on  both  computing  elemeVts  and  languages,  there  is  an  opportunity 
to  make  similar  advances  in  the  environment  inj which  systems  can  be  designed. 


''The  design  and  development  environment  for  software  has  grown  from  the  basic  needs  of 
assembler  to  the  wider  requirements  of  higher  order  languages,  ■fh^jjse  of  the  latter  has 
also  witnessed  a  growing,  but  disparate,  use  of  tools  associated  witff  the  design  process. 
Language  standardisation  has  presented  the  opportunity  to  produce  powerful  software 
development  environments,  j,,  'flu. 


The  future  poses  significant  challenges  in  thatAit  will  be  difficult  to  satisfy  the 
growth  in  computing  capacity  and  complexity  without  at  least  ten-fold  improvements  in 
productivity.  ALsxx^  although  the  eventual  aim  is  a  single  higher  order  language* the 
jw*<rjee^.  route  towards  #this  ideal  will  still  require  the  support  of  several  languages. 


Integrity  and  cost  requirements  will  dictate  the  introduction  of  formal  verification 
techniques  to  all  levels  of  design  and  implementation.  The  use  of  VLSI/VHSIC  technology 
and  beyond  will  allow  the  designer  to  specify  components  andChenee^the  design  environment 
should  be  integrated  with  relevant  CAD  tools. 


These  prospects  are  discussed  and  illustrated  using  a  model  of  a  Comprehensive  Avionic 
System  Computing  Analysis  and  Design  Environmental!  CASCADE ) . 

Those  features  of  CASCADE  which  exist  today  are  described  and  its  progress  is  charted 
in  che  medium  and  long  term. 

t 
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INTRODUCTION 


Of  all  modern  technologies  the  one  that  continues  to  amaze  us  with  its  relentless 
progress  in  terms  of  density  and  performance  is  that  which  belongs  to  the  design  and 
manufacture  of  digital  systems.  The  trends  experienced  over  the  last  decade  seek  to  repeat 
themselves  over  the  next  ten  years  and  in  doing  so  will  cause  us  to  continually  re-examine 
the  way  in  which  we  apply  the  technology.  By  implication  this  will  also  cause  us  to 
establish  how  we  make  maximum  use  of  the  technology  in  whatever  applications  are  considered. 


Comprehensive  reviews  of  the  state  of  the  art  abound  and  there  have  also  been  some  very 
useful  predictive  papers  discussing  not  only  digital  technology  trends  but  also  the  impact 
on  the  design  process  (1).  Taking  a  parochial  view  one  can  chart  the  progress  over 
sucessive  aircraft  projects  that  have  involved  the  Warton  Division  of  British  Aerospace  over 
the  last  25  years  and  in  particular  the  comparison  of  several  generations  of  electronics 
associated  with  computing  on  the  aeroplane. 


Fig.  (1)  treats  this  as  a  "Computing  Cube"  where  trends  are  shown  for  both  power  and 
cost.  The  power  function  is  expressed  as: 

Speed  in  operations  per  /sec  x  Memory  size  in  bits 
Volume  in  cuins 

and  shows  a  trend  of  about  two  orders  of  magnitude  improvement  per  decade.  A  mid  seventies 
data  point  is  qualified  as  a  single  airborne  computing  centre  capable  of  .05  MIP  and  with 
0.15  MBITS  of  memory.  A  late  1990's  point  could  consist  of  several  such  computing  centres 
each  capable  of  3  MIPS'  with  10  MBITS  of  memory. 


Despite  this  improvement  the  relative  cost  of  the  unit  volume  of  computing  is  falling 
at  about  an  order  of  magnitude  per  decade. 

These  locally  experienced  trends  confirm  the  more  general  ones  attributed  to  the 
technology  and  there  is  both  a  commercial  and  military  commitment  to  maintaining  them. 

The  commercially  based  VLSI  programme  both  in  Japan  and  the  United  States  is  complemented 
by  the  VHSIC  and  VHPIC  programmes  in  the  U.S.  and  United  Kingdom  respectively.  There  may 
be  varying  degrees  of  emphasis  between  the  two  domains  but  the  consequence  will  be  the 
same  with  massive  computing  power  becoming  available. 

It  would  be  foolish  to  assume  that  we  will  not  wish  to  fully  exploit  such  computing 
power  in  avionic  systems  and  again  experience  shows  us  that  the  availability  of  performance 
has  been  a  limiting  factor  in  successive  projects.  This  experience,  of  course,  is  not 
limited  to  the  avionic  fraternity. 
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However,  to  fully  exploit  this  growth  in  computing  power  we  will  almost  certainly 
have  to  venture  into  computing  architectures  not  to  be  found  in  the  avionic  systems  of 
today.  For  example,  architectures  which  will  support  and  make  use  of  multiple  processors 
yielding  greatly  increased  computational  capacity  through  parallelism  with  fully  distributed 
rather  than  federated  control.  This  degree  of  parallelism  will  be  capable  of  being  realised 
at  the  chip  rather  than  the  board  level  and  in  doing  so  will  necessitate  the  ability  to 
specify  integrated  circuits  which  are  tailored  to  particular  applications  but  made  up  from 
general  purpose  computing  elements. 

These  ideas  will  be  discussed  in  more  detail  in  later  sections  but  it  is  believed 
that  we  must  be  considering  the  environment  in  which  such  systems  will  be  developed.  It  is 
ihax  cm  groaur.  r  ’  v-  fan# a  mil  inm  wuirn  at  u<f  im  a"gn  jrc'blBM 

themselves  along  with  the  methods  and  tools  we  need  to  solve  them.  Such  an  environment 
should  be  as  comprehensive  as  possible,  supporting  not  only  the  detailed  design  phase  but 
also  all  other  relevant  parts  of  the  product  lifecycle. 

In  order  to  minimise  duplication  of  facilities  and  in  order  to  span  several  generations 
of  technology  it  should  be  capable  of  supporting  not  only  software,  embracing  several 
languages,  but  also  the  specification  and  design  of  hardware  of  the  kind  outlined  above. 

The  computing  to  oe  lounc  in  luture  avionic  systems  win  need  consideraoiy  more  effort 
invested  in  design  and  analysis  at  the  expense  of  testing  as  the  complexity  of  systems  will 
make  comprehensive  testing  impossible.  This  tendency  for  proof  in  design  rather  than  by 
re&i  atteierate  ti.e  mo ns  ioww zz  ir-sreasec  In w-a* me; t  ir  the  earlier  pnaeea  cl  r: 4 

product  lifecycle.  A  model  environment  to  support  such  a  trend  is  discussed  here  termed 
CASCADE  or  a  Comprehensive  Avionic  System  Computing  Analysis  and  Design  Environment. 

HISTORY 

Design  of  airborne  digital  systems  is  still  in  its  infancy  despite  the  rapid  growth 
in  technical  capability,  however  it  is  possible  to  draw  upon  some  U.K.  experience  in  order 
to  establish  a  small  number  of  data  points  in  the  growth  of  development  environments. 

Warton  Division  experience  in  digitally  based  airborne  systems  can  be  charted  over 
the  past  fifteen  years,  the  three  major  programmes  being  the  Jaguar,  Tornado  IDS  and  ADV 
aircraft . 

Although  initial  work  on  the  Jaguar  started  in  the  mid  sixties  it  was  1968  before  the 
choice  of  avionic  system  became  clear.  A  certain  amount  of  development  work  had  already 
been  done  on  some  of  the  equipments  but  a  considerable  amount  ( 8 K )  of  main  computer 
software  development  remained.  The  very  basic  tools  consisted  of  a  two  pass  assembler, 
link  editor  and  loader  with  minimal  test  or  monitor  software  in  the  accepted  sense. 

The  early  seventies  saw  the  beginning  of  work  on  the  Tornado  IDS  avionic  system 
requirements.  Despite  some  limited  distributed  computing  this  system  consisted  of  a 
centralised  computing  architecture  based  on  a  single  Litef  Spirit  III  with  eventually  6UJC 
words  of  memory.  The  assembly  language  associated  with  the  computer  was  consciously  chosen 
for  the  implementation  rather  than  a  higher  order  language  on  the  basis  of  performance  and 
availability.  The  major  functions  implemented  include  navigation,  displays  and  weapon 
aiming . 

System  requirements  were  produced  in  the  form  of  performance  and  design  requirements 
(PDR)  and  subsequently  subsystem  specification.  The  former  acted  as  the  formal  contractual 
basis  for  agreement  between  the  particular  companies  responsible  for  the  Tornado  and,  as 
(2)  outlines,  for  convenience  in  terms  of  specification,  functional  commonality  and 
operational  specialisation,  the  avionic  system  was  divided  into  a  number  of  subsystems. 

For  software  these  included : 

-  Navigation 

-  Displays  and  Controls 

-  Weapon  Delivery 

-  Terrain  Following /Automatic  Flight  Director 

and  for  each  a  definitive  specification  was  produced  expressing  the  PDR  in  more  detail  both 
functionally  and  in  terms  of  engineering  and  performance. 

Software  requirements  were  then  produced  reflecting  the  functional  and  operational 
requirments  of  the  subsystem  specification  in  more  detail  including  relevant  interfaces, 
software  tasks  and  crew  procedures  together  with  logic  and  equation  development. 

Basic  design  or  the  establishment  of  the  software  architecture  was  within  two 
frameworks 

-  a  program  structure  hierarchy 

-  the  features  offered  by  the  supervisor  or  executive  software. 

The  program  hierarchy  consists  of 

-  Operational  flight  program 

-  Subsystem,  a  functional /operational  subdivision 

-  Package,  basic  relocatable  program  unit  for  program  assembly 

-  Task,  to  allow  selective  iteration  and  iteration  rate. 
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Further  subdivision  is  possible  at  the  package  and  task  levels  into  routines  and 
subroutines  where  the  former  is  a  conventional  software  subdivision  and  the  latter  is 
aimed  at  commonly  used  ’  level  functions. 

Programs  were  designed  and  coded  in  the  Spirit  III  assembler  language  following  a 
staged  release  philosophy  and  submitted  to  a  number  of  levels  of  testing.  With  the 
exception  of  modelling  to  support  the  production  and  validation  of  software  requirement 
documents  the  latter  represents  the  first  use  of  software  tools  encountered  in  the  lifecycle 
and  for  brevity  we  will  describe  them  as  usea  at  each  stage  of  testing. 

Stage  1  is  the  environment  in  which  programmers  generated,  developed  and  tested  their 
software  and  consists  of  two  functions. 
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assembler  and  an  emulator.  The  assembler  provided  the  creation  of  source  and  its 
conversion  to  object  code,  syntax  checking,  error  reporting,  listing  (with  cross 
referencing}  editing  and  linkage.  The  emulator  is  a  software  model  of  the  SPIRIT 
III  Instruction  set  in  which  new  software  can  be  run  and  checked  for  storage  and 
time  requirements. 

-  IE  consists  of  a  stand  alone  target  computer  on  which  theOFP  can  be  statically 
ar.d  to  some  extent  dynamically  tested.  External  stimulation  and  monitoring  is 
provided  through  a  link  to  a  PDP-11. 

Stages  2  and  4  embrace  hardware /software  integration,  system  integration  and  avionic 
rig  acceptance  with  stages  3  and  5  providing  airborne  testing 

It  is  clear  that  a  development  environment  was  only  considered  necessary  from  the 
coding  stage  onwards  and  that  maximum  effort  was  devoted  to  the  testing  hases . 

An  implementation  representative  of  the  mid  seventies  is  to  be  found  in  (3)  in  the 
software  for  the  Sea  Harrier  HUDWAC.  Without  describing  it  in  some  detail  it  differs  in 
two  respects  from  the  one  described  above. 

-  the  approach  to  partitioning 

-  the  use  of  a  higher  order  language 

These  differences  are  not  unique  to  this  implementation  but  illustrate  a  general 
trend  in  avionic  software.  Partitioning  of  the  software  requirements  into  functional  tasks 
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below  this  level  each  task  may  consist  of  a  number  of  modules.  A  module  is  a  single  program 
containing  one  or  more  procedures,  which  is  specified,  written  and  initially  tested  in 
isolation  from  other  modules.  The  function  and  input /output  interface  of  each  module  can 
be  specified  together  with  guidelines  for  how  it  should  be  tested.  The  implementation  led 
to  programs  being  written  in  CORAL  60  with  the  attendant  advantages  of  visibility  and 
productivity.  A  hosted  cross  compiler  was  used  producing  binary  code  for  a  stand  alone 
computer  test  facility  with  appropriate  peripherals  and  monitoring  software. 

The  above  examples  help  to  set  the  scene  for  the  gradual  expansion  of  awareness  of 
the  importance  of  earlier  phases  of  the  lifecycle,  growing  from  the  assembly  language 
level  outwards.  This  awareness  has  crystallized  into  the  following  trends: 

-  The  repeated  design  of  executives  over  several  projects  has  led  us  to  believe  that 
there  may  be  some  virtue  in  adopting  a  rationalised  executive  with  standard 
functions  and  features.  If  such  an  ideal  were  possible  it  would  not  only  assist 
the  design  process  but  provide  significant  benefits  in  the  form  of  portability, 
improved  basic  design  and  reduced  support  software  costs. 

-  Build  on  the  notional  hierarchy  of  requirements  already  in  use  to  provide  a  more 
formal  structure  and  finer  grain  of  detail  which  would  support  technical  as  well 
as  procedural  audits.  This  in  turn  would  not  only  improve  the  quality  of 
requirements  (a  very  cost  effective  step)  but  also  maintain  a  more  detailed  user 
view  of  the  system  being  considered,  assist  traceability  and  enable  conformance 
to  be  established  between  requirements  and  design. 

-  Widen  the  use  of  software  tools  to  ascertain  quality  beyond  tha  boundaries  of 
code  and  test.  Testing  is  a  valid  and  important  aspect  in  the  production  of 
software  but  it  is  expensive  and  the  correction  of  errors  is  costly  at  this  stage. 
More  formal  methods  of  production  and  in  particular  requirements  should  allow  the 
use  of  software  tools  earlier  in  the  lifecycle. 

The  range  of  tools  employed  on  Jaguar  and  Tornado  IDS  are  shown  in  Table  (1)  which 
is  a  slightly  modified  form  of  the  comprehensive  table  to  be  found  in  (4).  How  these 
trends  have  been  encountered  in  a  more  advanced  design  environment  is  discussed  below  but 
first  let  us  briefly  discuss  the  simple  underlying  model. 

MODEL 

The  very  simple  model  considered  here  consists  of  the  phase  orientated  approach,  each 
phase  being  supported  by  appropriate  methods  and  tools.  The  particular  phases  chosen  are 
shown  in  Fig  (2)  and  embrace  the  production  process  from  system  requirements  to  maintenance. 
Whilst  not  wishing  to  discuss  the  relative  merits  of  phase  and  process  orientated  approaches 
here  it  must  be  admitted  that  there  is  a  significant  amount  of  iteration  not  shown  in  the 
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diagram.  This  iteration  occurs  not  only  between  phases  but  also  within  them.  These 
phases  are : 

-  System  Definition 

-  Software  Requirement 

-  Basic  Design 

-  Detailed  Design 

-  Code 

-  Test 

-  Maintenance 

Each  phase  produces  an  output  by  a  transformation  and/or  enhancement  of  the  input. 

This  process  should  be  supported  by  a  methodology  which  provides  order  in  the  development 
and  structure  to  the  product.  Put  another  way,  this  entails  the  steps  to  be  followed 
during  development  and  the  notation  to  be  used  in  expression.  This  in  turn  leads  to  more 
detailed  models  that  relate  to  activites  within  each  phase. 

The  remainder  of  this  paper  will  consist  of  two  uses  of  this  model  as  it  applies 
to  the  design  of  airborne  computing  systems.  The  first  relates  to  the  80-85  time  frame 
and  is  essentially  aimed  at  producing  software  systems.  The  second  is  relevant  to  the 
second  half  of  the  decade  and  includes  suggested  extensions  which  would  allow  the 
specification  of  custom  VLSI  based  systems. 

CURRENT  DESIGN  ENVIRONMENT 

The  design  environment  described  below  is  being  applied  to  the  embedded  computing 
for  an  avionic  system  cn  a  current  project.  It  is  considered  to  be  representative  of  the 
capability  expected  to  be  generally  available  up  to  the  middle  of  this  decade. 

A  specific  approach  is  described  in  terms  of  methods  and  tools  but  it  must  be 
stressed  that  there  are  probably  viable  alternatives  available  in  particular  areas  of  the 
environment . 

Semi  Automated  Functional  Requirements  Analysis  (SAFRA)  is  a  phased  lifecycle 
approach  with  a  consistent  set  of  methods  and  tools  for  each  phase.  A  comprehensive 
description  is  to  be  found  in  Ref.  (5). 

The  methodology  used  to  develop  and  express  requirements  is  Controlled  Requirements 
Expression  (CORE).  This  technique  was  developed  jointly  by  BAe  (Warton)  and  Systems 
Designers  Limited  and  embraces  a  method  for  the  assembly  and  analysis  of  information 
relevant  to  a  requirement  with  an  easily  understood  diagrammatic  notation  as  the  method  of 
expression. 

Two  automated  aids  to  production,  validation  and  storage  of  the  requirement  and 
software  design  are  a  CORE  graphics  workstation  and  the  University  of  Michigan's  Problem 
Statement  Language  and  Problem  Statement  Analyser  (PSL/PSA). 

The  software  design  interface  assumes  the  continuing  use  of  CORE  notation  to  produce 
detailed  specifications  with  storage  using  PSL/PSA  but  aimed  at  the  use  of  a  rationalised 
executive  and  higher  order  languages.  The  former  is  the  Modular  Approach  to  Software 
Construction  Operation  and  Test  (MASCOT)  and  the  latter  are  the  UK  MoD  standard  CORAL  66 
and  Pascal.  A  further  assumption  is  the  use  of  a  commercially  available  MASCOT  based 
software  development  and  test  environment  for  the  testing  phase  working  on  the  host-target 
principle,  such  as  CONTEXT  and  PERSPECTIVE. 

We  will  now  consider  the  environment  in  a  little  more  detail  under  the  general 
headings  of: 

-  Methodology 

-  Tools 

-  Lifecycle  products 
METHODOLOGY 

(a)  CONTROLLED  REQUIREMENTS  EXPRESSION 

CORE  is  a  method  of  analysing  and  expressing  requirements  in  a  controlled  and 
precise  manner.  It  enables  a  subject  requirement  to  be  expressed  as  either  a  number 
of  lower  level  requirements  or  as  a  component  part  of  some  higher  level.  Any  lower 
level  requirement  derived  using  CORE  may  in  turn  be  subjected  to  the  method  to  produce 
a  hierarchy  of  lower  levels.  The  lowest  level  is  that  at  which  the  full  method 
need  no  longer  be  applied  and  one  may  resort  to  strictly  hierarchical  decomposition 
making  use  of  the  notation  alone.  This  is  considered  to  occur  after  the  basic  design 
stage  has  taken  place.  In  general  the  same  notation  is  employed  at  all  levels  of 
requirement  and  design. 

CORE  diagrams  utilise  boxes  to  represent  processes  and  arrows  to  represent  data. 
The  diagrams  are  time  ordered  from  left  to  right  and  thus  the  box  ordering  specifies 
the  sequence  in  which  processes  must  occur.  Symbol  free  boxes  shown  ir.  parallel 
indicate  indeterminate  order  and  overlapping  indicates  a  number  of  identical  processes 
occurring  in  parallel.  All  input  data  entering  a  CORE  diagram  is  referenced  to  a 
source  and  all  output  data  to  a  destination. 


The  method  comprises  eleven  logical  steps  which  when  applied  to  a  subject 
requirement  will  decompose  it  into  its  lower  level  components  but  we  will  limit  our 
description  here  to  the  following. 

The  method  has  three  stages  for  each  level  of  decomposition  which  may  be 
summarised  as  - 

-  Information  Gathering 

-  Propose  Relationships 

-  Prove  Relationships 

Information  is  gathered  with  respect  to  a  number  of  subdivisions  of  the  problem, 
referred  to  as  viewpoints,  in  terms  of  input  and  output  data  and  gross  functions. 

This  information  is  refined  by  a  Data  Decomposition  step  which  specifies  in  more 
detail  the  data  already  tabulated. 

Relationships  are  proposed  between  the  inputs  and  outputs  for  each  viewpoint 
in  turn  and  for  data  flowing  across  the  viewpoint.  The  proof  of  such  relationships 
is  done  in  two  ways;  first  the  inter-relationship  between  viewpoints  is  examined  and 
where  such  links  exist  then  combined  diagrams  are  drawn.  Secondly,  as  these  represent 
only  particular  paths  through  system  operation  another  diagram  is  required  which  will 
illustrate  such  aspects  as  parallelism  and  the  operational  time  ordering  of  processes. 
Examples  of  both  diagrams  are  given  in  Figs  (3)  and  (4). 

The  outcome  of  the  above  is  a  partitioned  description  (in  terms  of  Viewpoints) 
with  a  detailed  and  hopefully  complete  picture  of  how  the  Viewpoints  interrelate  and 
react  with  each  other  as  well  as  some  indication  as  to  the  major  functions  contained 
within  them. 

It  is  now  possible  to  extract  the  Subject  Viewpoint  as  the  one  of  interest  and 
in  turn  take  Viewpoints  which  describe  how  it  is  composed  and  repeat  the  methodology 
in  full. 

Such  decompositions  continue  until  functions  emerge  which  may  be  seen  to  be 
implemented  as  software  on  a  particular  processor  and  at  this  stage  it  is  possible 
to  enter  into  basic  design. 

(b)  MASCOT 

MASCOT  is  a  set  of  facilities  for  realtime  programming  containing  features 
concerned  with  systems  development  and  construction  which  include: 

-  A  formalism  for  expressing  the  software  structure  of  a  system  which  can  be 
independent  of  computer  configuration  and  programming  language. 

-  A  disciplined  approach  to  design,  implementation  and  testing  which  supports 
the  concept  of  modularity  for  real  time  systems  and  brings  about  added 
reliability  by  increased  control  over  access  to  data. 

-  An  interface  to  support  the  implementation  and  testing  methodologies  which 
is  provided  by  a  small  kernel  that  can  either  be  implemented  directly  on  a 
bare  machine  (for  operational  use)  or  on  top  of  a  host  operating  system 
(during  development)  as  well  as  software  construction  facilities. 

-  A  strategy  for  documentation. 

MASCOT  views  an  application  system  as  a  number  of  activities,  or  processes, 
which  operate  independently  and  asynchronously  but  which  co-operate  by  accessing 
shared  Intercommunication  Data  Areas  (IDAs).  Thus  the  system  can  be  seen  as  a 
network  whose  nodes  are  the  activities  and  the  IDAs  whose  directed  links  are  pathways 
for  data  flowing  between  activities  and  IDAs. 

Although  the  MASCOT  facilities  allow  great  variety  in  the  implementation  of 
IDAs,  it  has  been  found  useful,  for  design  purposes,  to  distinguish  two  conceptual 
classes  of  IDA  according  to  the  nature  of  the  data  flow  which  they  support.  These 
are  called  channels  and  pools.  A  channel  supports  undirectional  data  transmission, 
and  has  an  input  interface  associated  with  a  number  of  consumer  activities.  A  pool 
provides  a  permanent  data  area  in  which  data  remains  available  for  activities  to 
read  until  it  is  specifically  overwritten.  The  data  in  a  pool  does  not  have  the 
essential  transcience  of  channel  data  and  reading  it  does  not  imply  consumption, 
conceptually  it  has  a  simple  bi-directional  interface  with  associated  activities. 

MASCOT  system  designs  are  represented  by  Activity-Channel-Pool  (ACP)  diagrams 
and  the  logical  outcome  of  a  basic  design  phase  using  MASCOT  would  be  a  set  of  ACP 
diagrams  showing  the  identified  activities  and  how  they  are  related  through 
appropriate  IDAs.  Integrating  a  requirements  phase  using  CORE  with  a  basic  design 
phase  using  MASCOT  means  transforming  a  requirement  diagram  into  a  design  diagram  as 
illustrated  in  Fig.  (5). 


(c)  Software  Design  Scheme 


This  scheme  covers  the  basic  and  detailed  design  phases  of  the  lifecycle.  The 
objective  of  the  basic  design  stage  is  to  convert  the  requirements  expressed  in  CORE 
to  a  MASCOT  Activity-Channel-Pool  (ACP)  diagram.  The  software  requirement  for  a 
particular  processor  consists  of  a  comprehensive  data  set  comprising  data  flow  and 
operational  diagrams,  data  decompositions  and  some  textual  explanations. 

Of  this  data  set.  the  Isolated  ODerational  Diagram  is  most  nearly  analogous  to 
the  MASCOT  ACP  diagram  in  thac  the  operational  relationships  ami  the  inter¬ 
communicating  data  flows  are  depicted  between  co-operating  processes  over  ths  system 
lifecycle.  The  designers  task  is  to  take  each  process  and  assess  if  it  is  possible 
to  implement  it  as  an  activity  and  to  define  inter-process  data  as  formal 
Intercommunication  Data  Areas.  Since  the  requirement  data  set  will  to  a  large  extent 
provide  the  data  decompositions  it  is  a  relatively  easy  matter  to  define  the  IDA  data 
structures  and  test  for  feasibility  of  basic  design  bearing  in  mind  the  nature  of 
data  driven  synchronisation  primitives. 

Detailed  design  for  the  activities  involves  what  is  in  normal  terms  'structured 
program  design'  but  in  CORE  terms  is  called  layer  decomposition.  Each  process  box 
which  comprises  the  upper  level  activity  is  taken  in  turn,  examined  and  a  more 
detailed  CORE  diagram  produced  using  the  standard  notation.  If  further  statements 
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corresponding  to  a  simple  design  algorithm  or  assignment  is  reached  and  at  this  layer 
the  activity  is  fully  decomposed. 

The  coding  stage  or  transformation  into  a  higher  order  language  now  takes  place 
with  the  assistance  of  PSL/PSA  but  this  will  be  discussed  below  in  the  section  on 
tools . 

THE  CORE  WORKSTATION 

The  CORE  workstation  aims  to  provide  maximum  computer  assistance  in  the  application 
of  the  CORE  method.  It  consists  principally  of  a  means  of  entering  CORE  diagrams  at  a 
graphics  screen,  storing  them  on  disk  and  subsequently  amending  them,  again  from  the  screen 
Hard  copy  of  the  diagrams  is  obtained  using  a  printer  plotter  and  some  automatic  checking 
is  provided  when  the  name  of  an  item  is  entered  on  a  diagram. 

The  interface  with  PSL/PSA  consists  of  automatically  converting  a  set  of  diagrams 
into  PSL  source  and  transferring  this  to  the  IBM  mainframe  for  PSA  report  processing. 

The  basis  of  the  workstation  is  a  raster  graphics  generator  and  a  20"  high 
resolution  monitor  with  a  keyboard  and  joystick.  The  resolution  is  1536  by  1024  pixels 
and  both  a  graphics  and  an  alpha  screen  may  be  displayed  simultaneously  or  independently. 
The  software  may  reside  on  a  PDP11  or  the  VAX  series  of  machines. 

A  suite  of  graphics  commands  are  available  to  allow  construction  and  manipulation 
of  diagrams  including  MOVE  and  MERGE.  The  first  allows  one  or  a  number  of  interconnected 
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involved.  MERGE  allows  the  contents  of  two  diagrams  to  be  merged  and  in  doing  so  supports 
an  aspect  of  the  CORE  methodology  which  calls  for  the  examination  of  related  data  flow 
diagrams.  It  can  also  be  used  to  construct  and  utilise  templates  of  the  most  often  used 
diagram  formats. 

The  workstation  embraces  all  types  of  CORE  documentation  including  tabular 
information  gathering,  data  decompositions,  data  flow  and  operational  diagrams.  A  number 
of  user  reports  are  available  which  list  relevant  information  concerning  the  diagrams  on 
a  particular  database  and  both  the  process  and  data  names  used  on  them.  An  analyser  checks 
name  usage  across  all  relevant  diagrams  including  simple  syntax  and  compliance  with  PSL 
rules.  It  also  reports  all  other  diagrams  of  a  particular  type  that  make  use  of  an  item 
both  across  a  level  of  decomposition  or  down  the  diagram  hierarchy. 

Tlit  wui  Kstation  is  lxuKea  to  PoL/PSh  *  esu.qa.ng  on  an  rflb  3uo3.  VSL  xnput  i  lies  are 
generated  automatically  from  the  diagram  data  base  and  submitted  via  the  link  as  an  input 
to  the  PSL  data  base  held  on  the  mainframe.  PSA  reports  return  via  the  link  for  display 
at  the  workstation. 

PSL/PSA 

Pit  {fvooieui  Statement  Languag,  ;/vSa  (tvooiem  Statement  Anaiyser;  is  a  product  ol  the 
ISDOS  project  at  the  University  of  Michigan.  PSL  is  a  language  which  can  be  used  for  the 
description  of  a  variety  of  system  types  from  the  highest  level  to  the  lowest  while 
monitoring  hierarchical  and  inter-relationships.  It  is  English  like  and  has  some  18  object 
types  which  can  be  matched  to  the  various  features  of  the  system  to  be  described. 

Conventions  lay  down  the  way  in  which  CORE  features  are  described  using  PSL.  This 
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relationships  between  them.  Although  there  are  a  number  of  CORE  diagram  types  it  is 
important  that  object  types  and  their  relationships  are  consistent  across  all  documents 
since  they  will  eventually  all  te  stored  on  a  single  database  intolerant  of  inconsistencies 
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All  PSL  input  files  are  produced  automatically  from  a  diagram  database  on  the  CORE 
workstation.  PSA  allows  the  establishment  of  a  database,  the  running  of  reports  on  that 
database,  its  modification  and  Control.  Of  these  the  most  significant  features  are  the 
37  reports  available  to  the  definer  which  allow  him  to  access  information  in  a  number  of 
different  forms.  Obviously  the  richer  the  PSL  description  is  of  a  given  object  the  more 
can  be  made  of  PSA. 

The  broad  category  of  reports  are: 

-  Lists  of  names 

-  Matrix 

-  Structures 

-  Function  flow 

Reports  can  be  run  individually  or  combined  to  produce  very  powerful  analysis.  PSL/ 
PSA  is  used  to  store  and  analyse  CORE  requirement  datasets  for  consistency  and  completeness 
but  its  role  in  detailed  design  goes  even  further. 

The  layered  activity  diagrams  are  translated  into  PSL  at  each  layer  up  to  the  point 
where  decomposition  terminates,  i.e.  assignment,  decision  table  or  basic  construct,  and  it 
is  possible  to  allocate  the  high  level  language  and  store  it  in  the  database.  The  detailed 
design  phase,  therefore,  produces  a  database  which  contains  the  structure  of  the  eventual 
orogram  (in  PSL)  with  the  language  elements  embedded  in  it.  The  source  file  for  a 
particular  activity  is  produced  by  running  a  particular  suite  of  linked  PSA  reports  and  a 
special  formatter. 

PERSPECTIVE 

PERSPECTIVE  is  aimed  specifically  at  the  development  of  software  for  embedded 
CoiupuLel  systems  wi  itteii  Hi  taSual .  It  as  ah  ehnaheedient  l>T  all  eailiel  system  ei/'BibTl  , 
which  produced  programs  written  in  CORAL  66,  but  both  support  the  use  of  MASCOT  as  a 
design  methodology  and  as  such  are  interchangeable  in  the  lifecycle  approach  described 
ix art .  ,  Lfctacr*  c  xt  is  lii wt  ■will  f  estfi^t  u’tff  ilcseriptiot  here  ts 

PERSPECTIVE. 

The  major  components  are  shown  in  Fig  (6)  and  its  main  features  are  as  follows: 

-  To  support  the  methodology  used  in  software  design  and  provide  a  safe  execution 
environment  for  sequential  programs  in  a  concurrent  system. 

-  A  comprehensive  configuration  control  scheme  to  prevent  unauthorised  access  to 
software,  ensure  different  project  members  interact  in  a  controlled  manner  and 
to  provide  management  information  on  the  configuration  of  a  software  system. 

-  A  facility  to  load  application  software  into  a  target  computer  over  a  serial  link 
which  also  allows  debugging  of  the  software  remaining  on  the  target  from  a  host 
computer  terminal. 
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A  description  of  all  the  components  shown  in  Fig  (6)  is  beyond  the  scope  of  this 
paper,  the  reader  is  referred  to  (6),  but  they  are  summarised  below. 

Configuration  control  is  concerned  with  the  management  aspects  of  a  project  and 
implements  a  range  oi  commands  wmcn  acoiveiy  support  unis  /unction.  for  example, 
PERSPECTIVE  has  no  MODIFY  command,  instead  a  CREATE  command  is  used  to  create  the  next 
version  of  an  item.  PUBLISH  is  used  to  change  the  status  of  any  item  of  software  from 
"development"  to  "controlled".  The  former  versions  may  only  be  manipulated  by  their  owner 
but  controlled  versions  may  be  used  or  read  by  other  users  which  have  access  to  them. 

The  Query  facility  allows  inspection  of  the  database  including  searching  down 

The  Constructor  is  responsible  for  deducing  which  items  of  software  need  to  be 
compiled  in  order  to  construct  the  item  required,  extracting  all  the  necessary  interface 
definitions,  symbol  tables  etc  required. 

Host  checkout  provides  facilities  for  initial  static  as  well  as  full  dynamic  testing. 
Static  checkout  identifies  errors  in  the  use  of  Pascal  and  can  be  applied  to  a  single 
activity,  dynamic  testing  mu3t  be  performed  using  a  test  harness  and  can  be  used  to 
investigate  the  dynamic  behaviour  of  an  activity  or  subsystem. 

The  down  line  loader  allows  the  host  to  load  programs  into  the  target  computer. 
Loading  may  either  be  done  initially,  in  which  ease  the  entire  system  is  loaded,  or  it  may 
be  invoked  after  a  change,  in  which  case  only  the  code  which  has  been  affected  by  the 
4S 

The  PROM  formatter  takes  the  output  of  the  Constructor  and  is  capable  of  slicing  each 
contiguous  block  of  memory  both  vertically  and  horizontally  to  blocks  of  formatted  data  for 
PROM  programming  equipment.  The  online  checkout  tool  allows  the  user  to  connect  the  host 
computer  on  line  to  the  target  and  then  use  PERSPECTIVE  debugging  facilities  available  for 
host  checkout.  Debugging  commands  entered  at  the  host  result  in  messages  being  sent  up  and 
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down  the  line  and  the  appropriate  debugging  actions  taking  place  in  the  target. 

LIFECYCLE  PRODUCTS 

At  this  stage  it  would  be  useful  to  review  the  lifecycle  products  of  the  methods 
used  and  the  scope  of  the  tools  discussed  above.  Fig.  (7)  summarises  these  products  for 
the  lifecycle  phases  proposed  in  Fig.  (2)  and  depicts  the  scope  of  the  CORE  Workstation 
with  PSL/PSA  and  PERSPECTIVE  or  CONTEXT. 

Tift  litmibsi  v-f  levels  tf  Lccumpoaiiitii  ad*c.t&Wu  Isc  UoIiiiiViuL  and  EwlVuai-t 

Function  are  typical  but  need  not  necessarily  be  adhered  to  as  they  will  vary  with  the 
size  of  the  system  and  the  degree  of  uncertainty  about  the  original  requirement. 

From  an  operational  point  of  view  it  is  possible  for  the  user  to  participate  in  all 
tne  pTi  asea  of  tne  lifecycle  from  a  single  workstation .  Tire  following  otser  vatxoiio  may 
also  be  made : 

-  Users  are  working  in  a  procedural  yet  understandable  fashion  which  in  no  way  acts 
as  a  barrier  to  the  expression  of  originality  or  engineering  skills. 

-  Each  phase  is  supported  by  a  computer  based  tool  which  not  only  improves 
productivity  but  also  assesses  quality. 

-  The  products  are  held  on  a  database  for  all  phases  making  them  amenable  to  a  wider 
range  of  processing  such  as  analysis  and  simulation. 

CASCADE 

In  this  section  we  will  consider  the  class  of  design  environment  required  for  the 
latter  half  of  this  decade.  This  should  be  as  comprehensive  as  possible  in  its  treatment 
of  implementation  language  and  hardware  with  analysis  and  design  aids  for  all  aspects  of 
avionic  system  computing.  In  order  to  discriminate  between  these  objectives  and  those  of 
SAFRA,  it  will  be  referred  to  as  a  Comprehensive  Avionic  System  Computing  Analysis  and 
Design  Environment,  CASCADE. 

Some  of  the  design  problems  that  will  need  to  be  addressed  by  CASCADE  and  more  general 
observations  are  discussed  below: 

-  The  large  processing  requirements  demanded  by  future  applications  which  hope  to 
capitalise  on  miniaturised  general  processing  elements  will  contain  a  large 
degree  of  parallelism.  The  kind  of  system  architectures  that  will  efficiently 
achieve  this  for  a  wide  range  of  applications  is  as  yet  unknown.  The  problem  is 
twofold;  how  do  you  design  with  parallelism  in  mind  and  how  do  you  effectively 
combine  large  numbers  of  general  purpose  computing  elements  to  satisfy  such  a 
design? 

-  There  will  be  areas  of  computing  which  due  to  their  size  or  specialisation  will 
require  customised  integrated  circuits.  Currently  there  is  a  gap  between  the 
methods  and  tools  used  to  produce  requirements  and  the  CAD  employed  in  the 
specification  of  specialised  VLSI.  A  bridge  needs  to  be  built  between  the 
requirements  and  the  system  architecture  abstractions. 

-  Viewed  from  this  half  of  the  decade  the  most  important  future  software  design 
stream  appears  to  be  that  relating  to  Ada  which  despite  some  technical  criticism 
could  well  become  an  international  standard.  While  the  spirit  of  the  early 
STONEMAN  document  on  the  design  environment  embraced  requirement  specification  the 
currently  planned  Minimal  Ada  Programming  Support  Environments  (MAPSE)  appear  to 
only  cover  the  phases  related  to  software  development  (ie  the  phases  covered  by 
PERSPECTIVE  above).  Language  independent  design  has  been  achieved  in  some  measure 
within  SAFRA  but  CASCADE  would  need  enhancements  to  accommodate  Ada's  basic  design 
concepts,  specialised  programming  constructs  and  data  typing. 

-  Despite  the  adoption  of  Ada  we  will  have  to  support  current  languages  beyond  the 
end  of  the  decade  and  hence  CASCADE  must  include  the  ability  to  work  with,  for 
example,  CORAL  and  Pascal. 

-  As  more  of  the  airborne  decision  making  and  control  becomes  vested  in  computing 
then  the  integrity  requirements  and  quality  of  software  will  need  to  grow.  Coupled 
with  increasing  complexity,  testing  becomes  not  only  prohibitive  in  cost  but 
technically  impossible  and  hence  the  need  for  methods  of  verification  and 
validation  during  the  design  process.  Current  analysis  and  verification  techniques 
are  aimed  at  the  implementation  language  and  could  well  be  adopted  to  examine  the 
products  of  earlier  phases,  particularly  if  the  latter  have  discernible  structure 
and  are  computer  based. 

The  approach  advocated  with  CASCADE  is  an  evolution  of  the  phased  lifecycle  via  new 
phases  in  the  design  process  and  additional  processing  within  phases  which  already  exist. 

In  particular: 

-  Enhancing  the  processing  applied  during  the  requirements  phase. 

-  Multiple  paths  within  the  implementation  phases  to  cover  software  and  hardware 
design . 
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We  will  first  consider  some  additional  processing  that  could  be  brought  to  bear 
during  the  requirements  phase. 

Tit?  etrjCt.rt.  -'f  rT.-lywl,  t.  -jj-ii -r.  ’■It  ikiiJlltj  Nwraid!  uf  l* 

readily  accepted  and  particular  techniques  are  starting  to  become  established.  For 
example,  the  method  of  using  a  directed  graph  to  depict  a  sequential  program  and  then 
analysing  this  representation  to  ascertain  problem  areas  or  quality  of  structure.  The 
particular  approach  described  in  (7)  has  been  used  successfully  in  a  high  integrity 
application  within  the  Division.  It  is  currenlty  being  considered  within  SAFRA  as  a 
means  of  gauging  the  quality  of  mission  software. 

In  CASCADE  we  would  seek  to  apply  the  same  technique  to  higher  levels  of  design  and 
JwcfIwi  tarty  Sfe  thef  ir.  fr  form  Iv6(  O.a 

graph  notation,  as  Fig  (8)  illustrates. 

In  practice  an  intermediate  process  would  both  produce  the  directed  graph  and 
perform  the  subsequent  analysis  by  operating  on  a  database  containing  the  diagrammatic 
information.  With  time,  this  analysis  would  be  replaced  by  formal  verification. 

A  database  of  requirements  produced  using  CORE  and  PSL  contains  much  information  of 
direct  relevance  to  system  simulation  ana  modelling.  This  information  is  in  the  form  of  a 
definition  of  the  system  functions  or  processes  with  their  corresponding  input  and  output 
interfaces,  together  with  timing  details  relating  to  the  scheduling,  interrupt  priorities 
and  performance  requirements. 

When  combined  with  some  model  of  the  environment  which  could  'drive'  the  system  this 
information  can  be  used  to  simulate  the  system  over  a  particular  time  period,  providing 
4»TS  cti  T PS*  lifts t*  mWw  of 

performance.  It  is  envisaged  that  CASCADE  would  employ  a  standard  simulation  package  such 
as  SIMSCRIPT  or  GPSS  linked  to  the  database  to  enable  such  simulation  to  take  place. 

In  discussing  the  design  aspects  of  CASCADE  we  will  differentiate  between  the  basic 
and  detailed  design  phases. 

BASIC  DESIGN 

In  CASCADE  the  basic  design  phase  consists  of  transforming  a  representation  of  the 
requirement  into  an  architecture  that  reflects  the  medium  of  implementation.  The  starting 
point  is  taken  to  be  the  Isolated  Operational  diagram  (IOD)  mentioned  above  which  was 
shown  being  transformed  into  the  MASCOT  ACT  architecture. 

The  path  to  be  followed  for  Ada  is  not  very  far  removed. 

The  MASCOT  activity  and  the  IDAs  include  both  control  and  data  structures  and  being 
examples  of  the  object  orientated  approach  to  program  design  they  encapsulate  a  small  set 
of  software  design  decisions.  The  module  termed  an  activity,  is  not  an  isolated  subroutine 
or  data  structure  but  an  interrelated  set  of  procedures  and  data.  The  outside  world  is 
reached  only  through  the  IDA,  including  the  data  required  and  produced  by  the  activity, 
while  the  latter's  contents  remain  invisible  to  the  user. 

With  Ada,  the  module  becomes  a  package  and  has  two  parts,  a  specification  and  a  body. 
The  specification  of  the  package  acts  as  an  interface  describing  the  users  access  to  the 
service  provided  by  the  package  including  all  the  information  relevant  to  its  use.  The 
body  of  the  package  provides  details  of  the  algorithm  and  data  structures  that  implement  the 
function  of  the  package. 

An  initial  look  at  modelling  MASCOT  concepts  within  Ada  was  encouraging  and  we 
anticipate  no  major  problems  in  charting  the  transition  between  CORE  IODs  and  a  software 
architecture  consisting  of  Ada  modules. 

The  casic  design  phase  for  hardware  requires  a  different  aoproach  and  depends  upon 
the  class  of  system  being  considered,  we  will  first  examine  one  requiring  considerable 
parallelism  to  satisfy  its  performance. 

Again,  the  problem  is  one  of  transormation  from  requirements  to  design  using  a 
method  of  representation  which  denotes  the  architecture  of  the  final  product. 

Without  stretching  concepts  too  far  one  could  conceive  of  a  MASCOT  machine  in  which 
General  Purpose  Computing  Elements  (GPCEs)  host  the  activities  and  specialised  hardware 
satisfies  the  neds  of  IDAs.  The  sequential  process  behind  the  activity  would  be  implemented 
in  €?C£,  tff  Wj  hJfiESl  w*y,  with  u-  library  Lard-wart  -ptsifiestl-L  :m  fw 

the  different  kinds  of  IDA. 

However,  although  MASCOT  appears  to  satisfy  the  need  for  asynchronous  processes  with 
implied,  although  not  necessary,  concurrency,  as  a  methodology  J t  would  require 
modifications  in  order  to  fully  exploit  parallelism.  One  which  goes  some  way  towards 
making  this  possible  is  the  process  oriented  language  Occam,  developed  by  INMOS  in  the 
United  Kingdom. 

In  Occam  concurrency  is  conceivable  down  to  the  lowest  levels  enabling  even  isolated 

♦*„<*  tri  1eI  Wf  fr.h  rtf'  «»  mp  p  r*r>  1  t 

together  to  operate  either  in  sequence  or  in  parallel. 
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The  order  in  which  processes  are  executed  is  govered  by  three  mechanisms: 

-  Sequential  (SEQ) 

-  Parallel  (PAR) 

-  Alternate  (ALT) 

along  with  conventional  WHILE  and  IF  constructs.  Inter-process  communication  is  governed 
by  an  unbuffered  structure  called  a  Channel  (CHAN)  which  allows  information  to  pass  in  one 
direction  only  and  may  also  be  viewed  as  a  means  of  synchronisation.  It  behaves  therefore 
as  a  read  only  element  to  a  receiving  process  and  a  write  only  element  to  a  transmitter. 

Within  CASCADE  a  possible  link  between  the  requirement  and  a  multi  processor  system 
would  be  established  by  transforming  the  appropriate  CORE  diagram  into  Occam.  This  is  shown 
for  example  in  Fig  (9). 

DETAILED  DESIGN 

The  systems  considered  above  under  basic  design  all  lead  to  a  conventional  detailed 
design  element  of  the  lifecycle  in  that  they  eventually  involve  the  production  of  software. 
The  class  of  system  yet  to  be  considered  is  when  we  wish  to  produce  a  customised 
integrated  circuit  to  solve  a  computing  problem  without  recourse  to  a  collection  of  GPCEs . 

In  order  to  achieve  it  in  CASCADE  the  relevant  parts  of  the  lifecycle  need  to  be  modified. 
Specifically  we  would  introduce  a  duplicate  path  for  hardware  which  would  replace  basic 
and  detailed  design,  code  and  test  with: 

-  Architectural  Design 

-  Logic  " 

-  Circuit  " 

-  Layout  " 

Architectural  design  undertakes  the  partitioning  and  definition  of  relationships 
between  major  functions  as  identified  in  the  requirement,  from  a  designers  viewpoint. 

Logic  design  decomposes  these  functions  until  the  layer  commensurate  with  logic  elements 
is  reached  while  circuit  design  transforms  this  into  an  electrical  circuit  with  appropriate 
physical  quantities.  The  layout  phase  seeks  to  optimise  the  circuit  design  in  terms  of 
path  length  and  element  proximity. 

Each  phase  is  served  to  a  varying  extent  by  the  following: 

-  CAD  tools 

-  Descriptive  languages  plus  database  and  analysers 

-  Simulation 

-  Element  libraries 

-  Method  of  decomposition 

-  Optimisation  and  product  oriented  processing 

To  describe  all  of  these  categories  in  detail  is  not  only  outside  the  scope  of  this 
paper  but  also  precipitate  from  the  point  of  view  of  CASCADE.  However,  to  serve  as 
representative  examples  a  method  of  decomposition  and  a  descriptive  language  have  been 
selected  as  typical  of  those  that  would  satisfy  the  needs  of  CASCADE. 

A  suitable  methodology  for  decomposition  is  suggested  by  the  REST  Leaf  Cell  design 
system  (8)  and  a  layer  decomposition  undertaken  similar  to  that  used  in  the  detailed  design 
phase  of  SAFRA.  The  design  is  partitioned  into  small  manageable  pieces  called  cells  which 
are  similar  to  procedures  in  a  programming  language.  A  cell  is  considered  to  be  rectangular 
in  shape  and  all  geometrical  data  is  on  the  interior  of  the  rectangle  and  considered  to  be 
the  property  of  the  cell.  Each  cell  is  composed  of  other  cells  or  primitive  elements 
which  form  a  hierarchy  of  cells  equivalent  to  the  nesting  of  procedures. 

The  cells  of  a  structured  design  are  partitioned  into  two  types,  composition  and 
leaf  cells.  A  composition  cell  contains  other  composition  or  leaf  cells  while  a  leaf  cell 
contains  only  wiring  and  primitive  circuit  elements. 

The  layered  hierarchy  which  results  from  the  decomposition  of  cells  is  similar  to 
layering  employed  in  the  detailed  design  phase  of  SAFRA  where  instead  of  the  terminating 
layer  being  a  basic  construct  in  the  programming  language  it  now  occurs  with  the  contents 
of  a  leaf  cell.  The  description  at  this  stage  contains  the  most  primitive  functions 
(leaf  cells),  the  hierarchical  relationships  (composition  cells)  and  the  geometric  data 
associated  with  each  cell.  This  database  may  then  be  used  as  the  basis  for  subsequent 
phases  involving  circuit  design. 

Reference  to  a  database  implies  a  method  of  description  that  can  be  stored  in  this 
way  and  the  use  of  what  is  generically  referred  to  as  a  Hardware  Description  Language. 
Several  examples  of  HDL  abound  but  the  one  being  considered  within  the  context  of  CASCADE 
is  ELLA,  developed  by  RSRE  (9). 

ELLA  waa  designed  to  cover  a  wide  range  of  hardware  design  from  below  gate  to  above 
register  transfer  level.  The  language  includes  facilities  for  the  description  of  networks 
and  the  behaviour  of  nodes  and,  because  of  its  scope,  nodes  can  be  anything  from 
transistors  to  microprocessors. 
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In  ELLA  the  function  declaration  is  a  description  of  how  a  piece  of  hardware  is 
constructed.  It  must  be  instantiated  into  a  piece  of  hardware  before  inputs  can  be 
applied  to  it  and  outputs  obtained  from  it  and  the  constructs  that  realise  function 
instantiation  and  interconnection  are  MAKE  and  JOIN.  It  is  also  possible  to  avoid 
duplicating  instances  of  a  function  by  calling  a  function  and  naming  its  outputs  using  a 
LET  statement. 

ELLA  has  no  built  in  signals  but  instead  functions  may  have  inputs  and  outputs  of 
any  user  defined  TYPE  and  because  the  TYPES  of  all  data  are  supplied,  all  JOINS  may  be 
checked  by  the  ELLA  compiler  and  inconsistencies  detected.  The  language  supports  a  top 
down  approach  starting  from  a  structured  high  level  description  of  the  design,  circuits 
being  described,  simulated  and  interactively  debugged  at'  subsequent  levels. 

If  used  in  conjunction  with  the  leaf  cell  concept  then  a  low  level  cell  representing 
an  EXCLUSIVE  OR  function  would  be  described  in  ELLA  as  shown  in  Fig  (10). 

It  is  felt  that  the  largest  effort  in  the  construction  of  CASCADE  will  lie  in  the 
integration  of  tools  which  already  exist,  spanning  the  gap  between  requirements  and  design 
and  improvement  of  user  interfaces  rather  than  significant  original  development  of  specific 
methods  and  tools. 

Experience  during  the  development  of  SAFRA  has  shown  this  to  be  possible  for  software 
but  it  has  also  demonstrated  that  a  well  structured  expression  of  requirement  can  act  as  a 
useful  spring  board  to  other  kinds  of  implementation  and  as  such  will  act  as  an  important 
step  in  the  construction  of  CASCADE. 

CONCLUSION 

This  paper  has  attempted  to  chart  the  progress  of  the  airborne  computing  development 
environment  in  the  medium  and  long  term.  The  longer  view,  with  CASCADE,  is  still  a  fairly 
notional  one  and  is  currently  more  of  an  expression  of  principle  rather  than  specific 
methods  and  tools.  However,  it  is  felt  that  the  most  powerful  link  to  be  forged  is  that 
which  lays  between  customer  and  designer  or  the  bridge  between  requirements  and  design, 
whatever  the  medium  of  implementation. 

Experience  in  the  general  computing  fraternity  is  one  of  bringing  the  user  closer  to 
the  solution  of  his  problem  by  the  use  of  high  level  tools  and  more  usable  methods  of 
expression . 

It  is  felt  that  a  similar  trend  will  be  followed  in  airborne  computing  albeit  over  a 
much  longer  period  of  time  due  to  the  complexity  of  the  problem  at  hand. 
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TOOL  OR  APPROACH  ‘ 

SEQUENTIAL  LIFE  CYCLE 

ACTIVITIES 

SOFTWARE  SYSTEM 

RE-  IMPLE-  TEST  &  1NTE- 

QUIRE-  MEN-  VALIDA-  CRAT10N 

MENTS  DESIGN  TATI  ON  TION  &  TEST 

AUTOMATED  TEST  CENERATOK 

X  X 

AUTOMATED  VERIFICATION  SYSTEM 

X 

ASSEMBLERS 

X 

COMPARATORS 

X  X 

COMPILERS  6  INTERPRETERS 

X  X 

COMPILER  BUILDING  SYSTEM 

X 

COMPILER  VALIDATION  SYSTEM 

X 

CONSISTENCY  CHECKER 

X 

CORRECTNESS  PROOFS 

X  X 

CROSS  REFERENCE  PROCRAM 

X  X 

DATA  BASE  ANALYZER 

X  X 

DATA  DESCRIPTION  LANCUACE 

X  X 

DEASSEMBLER 

X  X 

DEBUC  AIDS 

X 

DECOMPILERS 

X  X 

DYNAMIC  TEST  STATION 

X  X 

EDITORS 

XXX 

ENCINEER1NC  SIMULATIONS 

X  X 

EMULATION 

X  X 

FLOWCHARTERS 

X  X 

INSTRUCTION  TRACERS 

X 

INTERFACE  CHECKER 

X 

LANCUACE  PREPROCESSOR 

X  X 

LIBRARY 

X  X  X  X  X 

LINKAGE  EDITOR 

X 

LOADER 

X  X 

MAP  PROGRAM 

X  X 

OVERLAY  PROCRAM 

X  X 

POSTPROCESSOR 

X 

PROCESS  CONSTRUCTION 

X  X 

PSEUDO  PROCRAMMINC  LANCUACE 

X  X 

REPORT  CENERATOR 

REQUIREMENTS  LANCUACE 

PROCESSOR 

X  XX 

RESTRUCTURING  PROGRAM 

X 

SIMULATOR 

X  X 

SOF1VARE  MONITOR 
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FIG  (3)  CORE  DATA  FLOW  DIAGRAM 
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FIG  (4)  CORE  OPERATIONAL  DIAGRAM 
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DISCUSSION 


T.E.Spink,  US 

Your  mention  of  the  need  for  customized  integrated  circuits  recognizes  a  real  need,  but  unfortunately  the  likelihood 
of  obtaining  them  for  military  purposes  only  appear  slim  since  custom  ICs  must  be  produced  in  large  quantities  to  be 
economically  feasible.  Current  trends  indicate  that  the  custom  IC  must  occur  in  large  quantities  within  an  avionics  ^ 
sensor  or  system  to  promote  quantities  which  are  economically  feasible  to  produce.  Ideally  it  is  desirable  that  these 
special  purpose  ICs  have  a  commercial  application,  but  that  is  usually  not  likely  since  they  art  customized. 


Author’s  Reply  ^ 

While  your  observations  on  cost  may  have  been  true  some  little  time  ago  I  felt  that  they  will  not  necessarily  be  so  in 
the  near  future.  The  increasing  use  of  Uncommitted  Logic  Arrays  (ULA)  for  example,  and  relevant  ULA  design 
facilities  have  enabled  the  customer  to  become  involved  in  the  chip  specification  process.  The  growing  availability  of 
ULSI  design  tools  and  its  appearance  of  “Silicon  Foundries”  mean  that  relatively  small  production  runs  of 
customised  circuits  are  becoming  economically  feasible. 


F.W.Broecker,  Ge 

(1 )  Do  you  have  a  set  of  evaluation  criteria  if  you  analyse  the  simulation  of  requirements  in  increased  processing  in 
your  CASCADE-method? 

(2)  Do  you  agree  that  the  kind  (qualitative  and  quantitative  and  realism)  of  evaluation  criteria  has  a  vital  impact  on 
the  result  of  analysis? 

(3)  Do  we  need  a  common  set  of  evaluation  guidelines  and  criteria  for  any  kind  of  methodology  for  soft-  and 
hardware  system?  (This  includes  CASCADE  as  well). 

Author’s  Reply 

(1)  Clearly  the  exact  nature  of  evaluation  criteria  will  vary  with  the  nature  of  the  application  being  simulated  but 
in  a  general  sense  performance  must  be  of  prime  importance,  whether  this  is  the  complexity  of  interpretation 
within  a  cockpit  or  the  accuracy  of  weapon  delivery. 

(2)  Yes  I  would,  as  in  any  venture  the  evaluation  criteria  are  designed  to  succeed. 

(3)  Comparative  studies  for  the  benefit  of  the  user  community  need  and  use  such  standard  guidelines  and  they  have 
been  widely  published  in  the  United  Kingdom. 
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-J>-This  paper  describes  a  programing  to  design,  construct  and  demonstrate  an  advanced 
jvionic  system  for  the  next  generation  of  tactical  combat  aircraft.f(Th«~f>rograms*=-i#= 
oeing  carried  out  by  British  Aerospace  at  Brough  with  the  prime abbJ'ective'oT' reducing 

development  risks  associated  with  the  rapid  advance  of  technology.  A  number  of 
factors  contribute  to  this  risk,  notably  the  dramatic  increase  in  system  capability  made 
possible  by  the  general  availability  of  LSI  and  VLSI  circuitry.  This  has  occurred  at  a 
time  when  the  next  aircraft  project  is  likely  to  have  a  single  seat  cockpit. 

Traditionally  independant  systems  can  now  be  linked  using  a  data  bus  to  provide  a 
fully  integrated  system  with  the  pilots  needs  foremost  in  mind.  The  system  is  based  on  a 
multi  bus  architecture  recognising  the* differing  integrity  requirements  of  different 
parts  of  the  system.  A  complete  aircraft  system  is  represented,  divided  into  functional 
groups,  and  includes  the  basic  aircraft  systems  such  as  hydraulics  and  fuel  management 
and  an  integral  maintenance  reporting  system. VJEhe  mission  systems  include  a  wide  range 
of  sensor  and  weapon  types#  ana  £he  practical  implications  of  introducing  Mil. Std. 1760 
or  the  associated  STANAG  3837AA  Standard  store  interfaces  are  being  studied. 

The  avionic  systems  are  linked  to  an  Advanced  jUockpit,  with  the  objective  of 
reducing  pilot  workload.  The  cockpit  makes  use  of  multi-purpose  displays  and  an 
integrated  approach  to  system  control.  A  display  of  the  out-of-cockpit  scene  is  provided 
to  allow  the  'pilot1  to  operate  the  controls  in  a  realistic  manner  and  so  provide 
representative  input  to  the  avionic  system.  - 

The  development  is  based  on  an  evolutionary  approach  through  a  series  of  readily 
identifiable  intermediate  stages.  Configuration  control,  procurement  and  management 
techniques  are  being  developed  in  parallel  with  the  avionic  system  itself.  This 
evolutionary  approach  will  allow  the  maximum  effectiveness  to  be  derived  from  the  recent 
technological  advances. 

1.  INTRODUCTION 

The  production  of  a  new  military  aircraft  poses  a  challenge  to  the  design  team, 
which  has  to  balance  capability,  cost  and  risk  to  produce  a  product  which  satisfies  a 
customers  operational  requirements  at  a  price  he  can  afford.  The  pace  of  new 
technological  developments  continues  to  grow,  offering  the  possibility  of  increasing 
system  capabilities  to  levels  only  dreamt  of  a  few  years  ago.  However,  because  of  these 
rapid  changes  it  is  very  easy  to  fall  into  the  trap  of  assjming  that  a  particular 
component  or  technique  is  readily  available  or  fully  understood.  A  customer  needs  to 
know  the  level  of  risk  he  is  accepting  at  the  begining  of  a  new  aircraft  project,  as 
problems  encountered  late  in  development  can  be  very  costly  to  rectify. 

Since  the  last  major  aircraft  development  programme  in  the  UK,  significant  advances 
have  been  made  in  the  miniaturisation  of  electronic  components.  Large  scale  and  very 
large  scale  integrated  circuits  (LSI  and  VLSI)  are  available  which  allow  computational 
power  to  be  applied  locally,  wherever  it  is  needed,  and  this  trend  is  continuing  into 
the  VHSIC  programme.  Traditional  system  boundaries  are  being  broken  down  and  the 
architecture  of  an  avionic  system  is  no  longer  clear.  Many  alternative  ways  of 
allocating  system  functions  to  Line  Replaceable  Units  (LRUs)  and  interconnecting  these 
units  are  possible,  and  this  confusion  has  been  aided  by  the  development  of  digital 
serial  time  division  multiplexed  data  transmission,  ie.  the  data  bus.  The  amount  of 
information  which  can  be  transferred  between  LRUs  is  no  longer  limited  by  the  weight  of 
inter-system  wiring. 

Whilst  system  capability,  in  terms  of  the  number  of  functions  available,  continues 
to  grow,  the  pilot  still  only  has  two  hands,  with  a  total  of  ten  fingers,  two  eyes  and 
two  feet.  We  can  try  to  increase  the  number  of  control  channels  open  to  the  pilot  by 
providing  direct  voice  input,  head  pointing  systems  and  synthetic  voice  output  devices. 
It  is  clear  however  that  we  can  only  go  so  far  in  this  direction  and  new  methods  of 
achieving  control  over  the  total  system  are  needed,  to  reduce  pilot  workload  generally 
and  to  achieve  Hands  On  Throttle  And  Stick  (HOTAS)  control  during  combat. 

In  an  attempt  to  answer  some  of  the  more  important  questions  raised  by  the  new 
technology  and  thereby  reduce  risk,  the  UK  Ministry  of  Defence  (MoD)  has  established  an 
Avionic  Systems  Demonstrator  Rig  (ASDR)  at  British  Aerospace  Brough.  The  project  was 
first  described  to  this  group  at  a  conference  on  tactical  airborne  distributed  data 
neuroma,  held  on  24th  June  1981,  and  subsequently  to  tne  13th  annual  conference  cl  lex* 
held  at  Seattle  during  August  1982.  The  Rig  is  now  well  established  having  overcome  a 
number  of  major  technical  hurdles,  and  has  become  a  tool  which  can  be  used  to  support 
the  development  of  new  aerospace  equipment.  The  objective  of  this  paper  is  to  examine 
the  Rig  as  a  concept  and  then  to  briefly  describe  the  progress  we  have  made. 
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2.  THE  REQUIREMENT 

Advanced  avionic  systems  for  the  next  generation  of  tactical  combat  aircraft  have 
been  studied  by  the  UK  MoD,  with  the  support  of  British  industry  for  a  number  of  years, 
and  whilst  many  conclusions  have  been  drawn.  It  was  recognised  that  significant 
experience  could  be  gained  with  the  new  technology  in  a  ground  based  rig,  in  order  to 
provide  a  lead  into  the  next  aircraft  project.  Sucn  a  programme  could  reduce  the  risk 
factor  and  allow  a  more  advanced  system  to  be  implemented  in  the  future  aircaft  tb»n 
would  otherwise  be  possible. 

The  need  for  such  a  rig  programme  was  accepted  by  the  UK  MoD  in  the  late  1970' s, 
with  the  present  project  commencing  early  in  1980  following  extensive  discussion  within 
British  industry.  A  number  of  overall  objectives  were  defined  and  agreed  with  the  MoD  to 
form  the  ground  rules  on  which  the  Rig  was  built.  These  are  far  reaching,  covering  both 
technical  and  managerial  aspects.  As  listed  below  the  overall  objectives  are: 

.  to  support  the  development  of  avionic  systems  for  a  future  tactical 
combat  aircraft 

.  to  provide  practical  experience  with  an  advanced  avionic  system  using 
data  bus  communication 

.  to  demonstrate  the  techniques  of  software  management 

.  to  support  the  development  of  new  maintenance  procedures 

.  to  investigate  the  specification,  procurement  and  management 
procedures  required  to  develop  future  avionic  systems 

.  to  develop  new  system  control  strategies  and  to  demonstrate  the 
acceptability  of  these  to  the  pilot 

.  to  provide  a  national  facility  to  support  the  development  of  future 
projects 


3.  THE  METHOD 

The  ASDR  provides  a  substitute  for  a  real  aircraft  project,  and  whilst  the  future 
aircraft  configuration  remains  unclear,  the  architecture  of  an  avionic  system  suitable 
for  such  an  aircraft  can  be  defined.  The  specification,  procurement  and  integration  of 
that  system  then  form  the  basis  of  the  project. 

Any  new  avionic  system  will  rely  on  the  data  bus  to  provide  the  main  method  of 
communication  between  components  of  that  system.  Hence  the  development  of  a  data  bus 
based  on  the  UK  Defence  Standard  00-18  (Part  2)  must  be  the  starting  point.  The  first 
stage  of  the  project  is  therefore  to  construct  and  operate  a  dual  redundant  data  bus  and 
to  use  this  to  transfer  data  in  a  representative  manner  between  elements  of  a  simple 
avionic  system.  This  requires  the  specification  and  construction  of  a  bus  controller  and 
remote  terminals,  and  from  the  outset  it  was  decided  to  implement  all  transmission  modes 
including  broadcast  and  acyclic  transactions.  Once  the  bus  is  available  then  simple 
system  simulations  can  be  produced  to  generate  representative  data.  The  problem  of 
system  control  is  also  introduced  at  this  early  stage,  and  in  order  to  produce  realistic 
control  inputs  it  was  decided  that  a  'pilot'  should  be  included  in  the  control  loop. 

It  was  considered  unlikely  that  a  future  rvionic  system  would  use  only  a  single  data 
bus.  The  dissimilar  redundancy  and  integrity  requirements  of  various  parts  of  the  system 
and  the  natural  functional  partitioning  of  the  system  lead  to  a  multi-bus  architecture. 
Stage  2  of  the  rig  development  therefore  includes  expansion  of  the  avionic  system  to 
include  additional  buses.  This  requires  the  development  of  inter-bus  communication 
techniques  and  the  production  of  a  bus  controller  which  is  also  a  remote  terminal  on  a 
second  bus. 

The  expansion  in  the  complexity  of  the  system  and  the  quantity  of  dynamic  data 
produced  at  Stage  2  requires  the  development  of  bus  monitoring  and  analysis  techniques, 
beyond  the  capability  of  commercially  available  equipment.  Also  possible  at  this  stage 
is  the  development  of  a  maintenance  philosophy  and  monitoring  equipment.  The  cost  of 
maintaining  existing  aircraft  is  very  high  and  an  improvement  in  this  area  was 
recognised  to  offer  potentially  large  savings  in  the  cost  of  ownership  of  the  next 
aircraft.  The  equipment  used  to  provide  maintenance  data  should  ideally  simply  monitor 
data  on  the  buses  and  not  require  any  special  features  to  be  introduced  into  the  avionic 
equipments. 

Stage  3  includes  expansion  to  represent  a  full  avionic  system  and  therefore  involves 
the  specification  and  prpcurement  of  many  items  of  equipment  from  avionic  suppliers.  To 
embark  upon  this  phase  Without  experience  of  the  procurement  procedures  represents  a 
large  risk  for  the  Rig  project.  A  number  of  the  equipments  for  Stage  2  are  therefore 
procured  from  industry  to  establish  these  procedures,  and  to  allow  time  to  amend 
procedures  found  to  be  deficient  before  committing  large  quantities  of  project  funding. 

Stages  1  and  2  establish  the  technological  base  and  managerial  procedures  necessary 
to  produce  an  advanced  avionic  system  using  data  buses.  However  the  system  implemented 
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at  the  end  of  Stage  2  is  relatively  simple  and  cannot  be  considered  to  fully  test  the 
new  techniques. 

Stage  3  closely  resembles  the  production  of  a  ’real'  aircraft  system,  involving 
system  definition,  specification,  procurement,  integration  and  operational 
demonstration.  The  design  of  the  Stage  3  avionic  system  was  bounded  by  adopting  the 
following  guidelines: 

.  the  system  should  be  representative  of  that  required  for  a  tactical 
combat  aircraft 

.  the  system  is  intended  to  support  a  wide  variety  of  projects  and 
therefore  requires  flexibility  wherever  possible 

.  the  system  requires  to  be  separate,  both  philosophically  and 
practically  from  the  'outside  world'  stimulation 

It  is  necessary  to  make  assumptions  about  the  nature  of  the  operational  requirements 
for  the  aircraft  whose  systems  are  represented  on  the  Rig  and  to  establish  performance 
levels  which  affect  the  avionic  requirements.  In  particular  the  aircraft  missions  must 
be  defined  and  hence  the  approximate  aircraft  size  and  capability.  In  addition  it  is 
necessary  to  define  the  weapon  loads  required  to  fulfil  those  missions. 

The  system  is  specified  at  the  functional  level  with  a  functional  requirement 
specification  being  produced  for  each  system  element,  describing  what  that  element  is 
required  to  do,  but  not  how  it  will  be  implemented.  These  specifications  serve  two 
purposes:  to  provide  the  raw  material  from  which  the  total  system  architecture  can  be 
derived,  and  to  provide  the  basis  from  which  the  system  procurement  can  proceed.  In 
order  to  procure  equipments  then  the  functional  elements  must  be  allocated  to  hardware 
units,  bearing  in  mind  the  practical  constraints  imposed  by  aircraft  installation 
factors.  Constraints  are  also  imposed  by  the  ground  rig,  such  as  development  timescales, 
the  desire  wherever  possible  for  flexibility,  implementation  limitations  to  constrain 
costs,  and  limitations  imposed  by  the  'outside  world'  stimulation  facility. 

Equipment  procurement  specifications  are  then  produced,  each  comprising  two  parts. 
Part  1  is  common  to  all  specifications  and  includes  conditions  which  are  applicable  to 
all  equipments  eg.  available  power  supplies,  and  the  preferred  programming  language. 

Part  2  contains  detailed  requirements  for  the  particular  equipment  and  should  be  written 
sufficiently  broadly  to  allow  each  vendor  flexibility  to  offer  proposals  that  they 
consider  to  be  advantageous  to  the  project.  At  the  same  time  it  should  be  sufficiently 
precise  to  guarantee  that  the  equipment  provided  will  fully  meet  the  defined 
requirements. 

Following  the  submission  of  proposals  the  choice  of  vendor  is  based  upon: 

.  compliance  with  the  Equipment  Procurement  Specification 
.  cost 

.  delivery  timescales 
.  design  advantages  and  disadvantages 

In  addition  to  the  specification  and  procurement  activity  there  are  the  large 
central  tasks  of  providing  the  'outside  world'  stimulation,  defining  the  overall  system 
control  mechanism  and  data  flows  and  integrating  the  systems  together. 

It  has  been  stated  that  one  of  the  prime  objectives  of  the  Rig  is  to  demonstrate 
system  acceptability  to  the  pilot.  Hence  in  addition  to  a  major  emphasis  in  the  cockpit 
design  on  the  ergonomics  of  the  pilot's  task  it  is  important  to  consider  pilot  workload, 
and  to  achieve  the  correct  balance  between  direct  pilot  interaction  and  automatic  system 
actions. 

Many  of  the  objectives  of  the  rig  programme  will  be  achieved  during  its  development, 
in  terms  of  procedures,  techniques  and  equipment  generated.  The  end  point  of  the  current 
project  is  considered  to  be  the  successful  demonstration  of  the  operation  of  the  defined 
system  over  a  number  of  defined  mission  phases. 

4.  THE  IMPLEMENTATION 

4.1  The  Rig  Facility 

To  house  the  Rig  and  the  Advanced  Cockpit  a  new  building  was  constructed  at  Brough, 
providing  laboratory,  office  accommodation,  computer  facility  and  a  demonstration  area 
based  on  the  cockpit  and  outside  world  display  system.  The  overall  Rig  facility  is  shown 
in  Figure  1. 


4.2  Developing  the  Data  Bus 

The  first  task  was  to  produce  a  data  bus,  and  this  was  achieved  by  first  developing 
sufficient  hardware  to  construct  a  simplex  bus  and  then  expanding  this  to  a  dual 
r uduiiibiir  otaiiddid  ttj  sdJiwij  uJitra  xTitez £ aCt  lid, Jttd.di  i W j  was  based  on  a 

commercially  available  microcomputer,  the  Plessey  MIPROC  16AS,  which  has  a  processing 
speed  sufficient  to  allow  the  necessary  DEF.  STAN.  00-18 (Part  2)  response  times  to  be 
me* .  difSWMe  f  *ce  is  we#e  dmltped  bf  3fi!,44h  ’  •f.‘»p*fe‘  lefznue  psaJUcsd 

to  cause  the  microcomputer  to  function  as  either  a  remote  terminal  or  bus  controller.  A 
Fairchild  data  bus  monitor/controller  completed  the  initial  system.  The  Rig  at  this 
stage  was  used  to  transfer  artificial  data  from  one  location  to  another  to  demonstrate 
all  bus  transfer  mechanisms. 

4.3  Stage  1 

Stage  1  capability  was  achieved  by  developing  software  for  the  MIPROCs  to  simulate 
system  functions.  A  dual  navigation  function  and  a  fuel  system  function  were  selected  in 
order  to  generate  a  wide  variety  of  data  types  and  rates  and  to  allow  investigation  of 
the  handover  between  duplicated  functions.  Software  for  the  MIPROCs  is  developed  on  a 
Digital  Equipment  Corporation  (DEC)  VAX  11/780  computer  and  downloaded  into  each 
microcomputer  at  the  start  of  a  run.  The  VAX  11/780  also  provides  the  outside  world 

cf  tbe  rysttnss,  ir  the  f.rm  tl  aei^Jynomic  and  errjibe  data,  ^uiside  world 
display  data  and  a  Rig  command  and  monitor  function. 

The  Stage  1  Rig  shown  in  Figure  2  is  completed  by  providing  pilot  control  and 
display  interfaces.  Advantage  was  taken  of  an  advanced  cockpit  development  programme 
already  cn.detway  at  atoogrr  to  pfwilk-  tfWiSe  tttiiitreS.  Tli<=  Mg  and  Advanced  Cockpit 
activities  are  complementary  and  allow  the  Rig  to  receive  realistic  control  inputs 
whilst  the  Advanced  Cockpit  activity  has  a  representative  avionic  system  to  control.  The 
combined  Rig/Advanced  Cockpit  facility  also  provides  an  excellent  demonstration 
capability. 

In  order  to  provide  the  interfaces  between  the  cockpit  and  the  Rig  a  number  of 
special  units  were  produced.  These  were  the  Controls  Management  Processor  which  formats 
switch  data  for  transmission  over  the  data  bus  and  receives  data  from  the  bus  to  drive 
discrete  warning  indicators  in  the  cockpit,  and  a  waveform  generator  pre-processor.  The 
Ferranti  waveform  generator  was  made  available  with  the  cockpit  and  the  pre-processor 
constructed  to  provide  the  remote  terminal  to  the  bus  and  some  display  data  processing. 
The  final  unit  shown  in  Figure  1  is  a  map  drive  interface  unit  which  is  needed  to  drive 
the  moving  map  function  of  the  Ferranti  COMED  head  level  display. 

4.4  Executive  Control 

The  major  achievement  of  Stage  1  has  been  the  development  of  an  embryo  Executive 
function  which  provides  much  of  the  automatic  system  control,  and  is  resident  in  the 
same  microcomputer  as  the  Bus  Controller.  Its  position  in  the  control  hierarchy  is  shown 
in  Figure  3.  Executive  control  is  that  control  of  the  total  system  which  manages  the 
combined  operation  of  the  various  sub-systems  to  achieve  the  requited  overall  state. 
Executive  control  uses  pilot  selections  and  sub-system  status  data  feedback,  in  the  form 
of  Status  Words  and  State  Response  Words,  to  generate  the  control  commands  to  the 
systems.  These  commands  are  transmitted  over  the  bus  in  the  form  of  State  Control  Words 
which  are  used  to  provoke  changes  in  the  overall  system  state.  The  changes  required  can 
be  as  a  result  of  pilot  interaction  or  as  a  consequence  of,  for  example,  a  sub-system 
failure.  One  particularly  useful  capability  of  such  a  system  is  the  ability  to 
reconfigure  the  total  avionic  system  automatically  according  to  the  mission  phases. 

It  is  tempting  to  use  the  Executive  function  to  control  all  system  changes.  However, 
such  a  centralised  system  would  require  an  unnecessarily  large  control  program. 

Following  detailed  study  it  was  decided  to  allow  sub-systems  autonomous  control  of 
tnose  internal  functions  wnieh  do  not  dirertly  effect  other  subsystems. 

4.5  Enhancement  of  bus  techniques 

At  Stage  2  a  second  data  bus  is  introduced  (Figure  4)  to  allow  investigation  of  the 
operation  cf  two  asynchronous  data  buses.  This  second  bus  is  referred  to  as  the  General 
Services  bu.  as  it  provides  communication  between  those  services  such  as  fuel 
management,  hydraulic  management,  environmental  control  and  electrical  power  generation 
which  are  basic  to  the  operation  of  the  aircraft.  The  general  services  bus  controller  is 
required  to  have  a  remote  terminal  onto  the  first  bus,  now  referred  to  as  the  avionic 
bus,  to  allow  inter-bus  communication. 

4.6  System  Procurement 

As  has  already  been  mentioned,  Stage  2  is  intended  to  test  procurement  procedures, 
and  so  the  bus  controllers  for  the  avionics  and  general  services  buses  were  specified 
and  procured  from  Industry.  rhe  problem  of  redundant  executive  and  bus  controller 
operation  is  investigated  by  specifying  two  bus  controllers  for  the  avionics  bus.  The 
dual  navigation  system  was  also  procured  from  industry  to  investigate  the  specification 
of  iaU  latw  tafia  And  B^abca  apalallon,  and  to  allow  &plu  um-q  ‘.id  tattgivLon 
procedures  to  be  established. 


4.7  The  Outside  Wor  Id  bus 
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Another  important  feature  of  the  Stage  2  Rig  is  the  clear  distinction  between  the 
avionic  system  and  the  "Outside  World"  stimulation.  The  Outside  World  has  been  provided 
with  its  own  bus  and  bus  controller  to  allow  communication  between'  the  general  purpose 
computer  and  those  functions  requiring  stimulation.  It  is  considered  too  difficult  and 
expensive  to  provide  real  aircraft  sensors  such  as  the  Inertial  Navigation  platform  and 
then  attempt  to  stimulate  them.  Instead,  emulations  of  the  sensing  functions  are 
provided  such  that  the  interface  with  the  rest  of  the  system  appears  to  be  realistic, 
but  with  the  sensor  data  being  supplied  over  the  Outside  World  bus. 

4.8  Redundant  displays  and  data  analysis 

Other  features  of  the  Stage  2  Rig  are  redundant  waveform  generation  for  the  pilot’s 
displays  and  the  addition  of  a  data  recording  and  analysis  system.  Redundant  display 
generation  was  provided  by  procuring  a  second  waveform  generator  and  pre-processor  and 
constructing  a  video  multiplexing  unit.  The  ability  to  monitor,  record  and  analyse  data 
bus  traffic  has  been  provided  by  developing  an  interface  to  the  Fairchild  Data  Bus 
Monitor/Controller  to  down  load  bus  data  into  a  mini  computer  and  then  onto  hard  disc 
storage.  An  analysis  program  operates  on  the  stored  data  subsequent  to  completion  of  the 
rig  run. 

4.9  Functional  Decomposition 

Stage  3  of  the  rig  development  expands  the  system  functions  to  include  all  those 
which  would  be  required  for  a  tactical  combat  aircraft.  To  help  define  what  those  system 
functions  should  be,  B.Ae.  obtained  the  support  of  a  group  of  senior  design  engineers 
from  a  number  of  the  largest  UK  avionic  suppliers.  This  group  performed  a  "Top  Down" 
functional  decomposition  of  the  complete  avionic  system,  within  the  overall  ground  rules 
mentioned  earlier,  and  produced  a  set  of  functional  requirement  specifications.  This 
approach  resulted  in  the  overall  system  being  divided  into  four  major  groups  of 
suD-ayc*-em  functions. 

.  the  Aircrati  group 

.  the  Pilot  group 

.  the  Navaids  group 

.  the  Mission  group 

The  Aircraft  group  comprises  those  avionic  sub-systems  which  are  concerned  with 
keeping  the  aircraft  flying  safely.  This  group  is  mainly  safety  critical  and  contains 
the  flight  and  engine  control  systems  and  the  general  aircraft  services  which  include 
fuel  management,  hydraulic  management,  the  control  of  aircraft  power,  environmental 
control  and  the  associated  sensors  and  actuators.  The  general  services  systems  are 
arranged  so  that  the  management  functions  are  distributed  and  associated  with  at  least 
two  processing  units.  Each  processor  would  be  expected  to  carry  out  one  of  the  main 
management  functions,  secondary  data  control  and  local  data  collection.  It  is  intended 
that  each  sub-system  should  be  capable  of  independant  but  reduced  operation  in  the  event 
of  a  complete  failure  of  the  General  Services  bus.  This  group  also  includes  a 
maintenance  data  recording  system  which  stores  both  trend  and  fault  diagnostic  data  from 
the  various  sub-systems.  The  data  is  stored  for  subsequent  retrieval  and  will  provide 
rapid  and  direct  interpretation  of  a  failure  by  ground  personnel.  More  detailed 
maintenance  data  is  available  for  off-line  analysis. 

The  Pilot  Group  embraces  what  are  normally  considered  to  be  the  cockpit  controls  and 
displays  facilities,  and  in  this  particular  architecture  also  contains  the  executive 
control  function.  The  displays  system  assumes  a  full  CRT  suite  of  four  displays, 
including  the  Head  Up  Display,  and  a  completely  independant  reversionary  display  system 
implemented  in  an  alternative  technology.  Clearly  there  is  a  limit  to  the  quantity  of 
imformation  which  can  be  absorbed  by  the  pilot  at  any  particular  phase  of  a  mission  and 
the  intention  is  to  provide  him  with  only  that  information  which  is  relevant  for  his 
immediate  task.  Hence  the  mission  has  been  broken  down  into  phases  such  as  Take-off, 
cruise  etc.  and  the  displays  organised  by  the  avionics  executive  function  to  provide  the 
appropriate  information.  The  controls  sub-system  is  based  on  a  multi-purpose  control 
panel  which  interacts  closely  with  the  avionics  executive,  and  dedicated  switches  which 
are  divided  into  two  side  consoles.  The  starboard  side  of  the  cockpit  is  used  for 
once-a-fl ight  switches.  The  main  attack  and  defensive  systems  can  be  operated  without 
the  pilot  having  to  take  his  hands  off  the  flight  control  stick  and  the  throttle, 
however  a  number  of  dedicated  system  selection  switches  are  still  required  and  these  are 
located  on  the  port  side  of  the  cockpit. 

The  Navaids  Group  of  system  functions  provide  the  basic  ability  of  all  aircraft  to 
navigate  and  communicate  effectively.  The  group  consist:]  of  inertial  sensors  and 
processing,  radio  navigation  aids,  communications  system  and  a  briefing  aid.  In  addition 
to  providing  basic  position,  attitude  and  velocity  data,  the  navigation  system 
calculates  the  required  heading,  track,  ground  speed  and  time-to-go  to  make  good  a 
desired  destination  or  route.  The  radio  navaids  include  the  TACAN  and  MLS  systems.  The 
briefing  aid  allows  the  pre-flight  insertion  of  data  into  systems  concerned  primarily 
with  navigation  and  weapons  control.  Extensive  use  is  expected  to  be  made  of  this 
function  to  reduce  the  amount  of  manual  data  entry. 
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The  Mission  Group  of  systems  include  the  basic  aircraft  sensors  such  as  the  radar 
and  electro-optic  systems,  the  Stores  Management  System  (SMS)  and  the  essential 
defensive  aids.  The  SMS  provides  safety  critical  outputs  and  a  data  bus  interface  to 
advanced  weapon  types  via  the  standard  store  interface  defined  in  Mil.Std.  1760  and  the 
associated  STANAG  3837AA.  Communication  between  units  of  the  SMS  is  again  achieved  with 
a  data  bus.  Attack  packages  will  be  set  up  from  data  briefed  into  the  system  at  aircraft 
start-up,  but  allowing  the  pilot  to  manually  override  the  initial  settings.  The  weapon 
aiming  function  is  distributed,  with  the  air-to-ground  processing  being  carried  out 
within  the  navigation  system  and  the  air-to-air  processing  within  the  Radar. 

4.10  The  Avionic  System  Architecture 

The  system  elements  identified  as  a  result  of  the  functional  decomposition  were 
brought  together  by  B.Ae.  to  form  the  architecture  of  the  avionic  system  to  be  produced 
during  the  Stage  3  expansion.  This  is  shown  in  figure  5.  The  resulting  system  is  in  many 
respects  more  comprehensive  than  would  be  included  in  a  single  seat  aircraft,  but 
provides  the  facilities  for  further  development  work. 

4.11  Timescales 

The  initial  contract  for  the  Rig  was  placed  in  mid  1980  and  it  is  intended  that 
Stage  3  will  be  complete  in  mid  1984. 

5.  PROGRESS  AND  PROBLEMS 

Stage  1  of  the  rig  development  was  completed  in  the  autumn  of  1981,  with  relatively 
few  major  difficulties.  Some  delays  were  incurred  through  the  unreliability  of 
commercial  equipment  and  the  use  of  compilers  which  were  found  to  be  incompletely 
tested.  The  main  task  of  proving  data  bus  communication  was  achieved  with  only  minor 
changes  being  required  during  the  integration  phase. 

Stage  2  has  proved  to  be  a  more  difficult  task  with  delays  being  introduced  during 
sub-system  development.  The  bus  interfaces  wore  no  longer  under  the  direct  control  of 
B.Ae.  and  hence  required  to  be  specified  in  considerable  detail  to  sub-contractors. 

Minor  deficiencies  or  ambiguities  in  the  specification  can  result  in  incompatibilities 
which  do  not  become  apparent  until  the  sub-systems  are  integrated.  The  process  of 
integration  has  also  proved  difficult  as  a  faulty  word  from  one  sub-system  can  have 
unexpected  results  in  other  parts  of  the  overall  system.  The  data  acquisition  and 
analysis  facility  has  been  found  to  be  a  very  important  diagnostic  aid.  New  system 
testing  procedures  have  had  to  be  developed  and  a  specialised  testing  facility  was  found 
to  be  required. 

As  expected,  all  major  difficulties  have  occurred  in  the  area  of  the  data  bus 
interfaces  and  lessons  have  been  learnt  which  are  now  being  applied  to  Stage  3. 
Specification,  development  and  testing  procedures  are  established  and  the  design  of  the 
bus  controller  and  executive  function  have  been  verified.  To  aid  the  production  of 
executive  software  various  software  tools  have  been  produced.  These  include  an  automatic 
program  generator  to  produce  the  finite  state  control  logic.  This  reduces  coding  errors 
and  has  a  user  orientated  input  stage.  A  further  program  allows  a  user  to  specify  state 
control  words  and  state  response  words  by  English  language  input.  It  is  difficult  to 
overstate  the  importance  of  the  executive  function  which  in  many  ways  is  the  heart  of 
the  new  avionic  system.  Without  it  the  avionic  architecture  shown  in  figure  5  would  be 
difficult  to  achieve  and  the  control  of  the  overall  system  by  a  single  pilot  would  be 
difficult  if  not  impossible.  The  control  functions  performed  by  the  executive  have 
allowed  the  number  of  control  switches  to  be  reduced  and  have  made  the  concept  of  the 
advanced  cockpit  a  viable  proposition. 

Stage  2  is  now  essentially  complete  and  a  large  amount  of  experience  has  been 
obtained.  Stage  2  has  achieved  its  prime  objective  of  generating  confidence  in  the  Stage 
3  expansion  programme. 

Stage  3  equipment  specification  and  procurement  has  been  underway  for  some  time  with 
some  systems  being  at  an  advanced  stage  of  development.  Major  lessons  have  still  to  be 
learnt  but  these  are  now  associated  with  the  management  of  data  interfaces  rather  than 
data  bus  techniques. 

6.  STATE  OP  THE  ART 

In  a  short  period  of  time  the  ASDR  has  allowed  significant  advances  to  be  made  at  a 
relatively  low  cost.  The  data  bus  is  no  longer  an  unknown  quantity  and,  whilst  care  is 
required  to  use  the  technique,  its  advantages  can  now  be  realised.  UK  industry  is 
generally  aware  of  the  new  design  approach  and  has  a  number  of  new  product  lines.  The  UK 
MoD.  is  gaining  the  confidence  it  needs  before  committing  large  amounts  of  money  to  a 
new  aircraft  project  and  has  a  design  tool  which  can  be  used  to  support  that  project. 

During  the  course  of  the  Rig  programme  many  new  possibilities  for  system  operation 
have  emerged  which  have  had  to  be  excluded  for  cost  or  timescales  reasons.  The  Rig  forms 
an  ideal  environment  in  which  to  develop  these  new  ideas  and  many  lines  of  future 
development  are  envisaged. 
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DISCUSSION 

J.F.Irwin,  US 

What  criteria  and  arguments  were  used  to  determine  what  system  elements  or  functions  are  assigned  to  a  specific 
bus  and  how  do  you  communicate  global  information  (i.e.  broadcast)? 

Author’s  Reply 

The  major  consideration  for  the  partitioning  of  buses  was  the  differing  integrity  requirements  of  certain  system 
groups.  For  example  the  general  services  or  utilities  functions  are  flight  safety  critical  and  so  they  are  kept 
segregated.  This  does  not  mean,  however,  that  the  loss  of  the  general  services  bus  hazards  the  aircraft  since  the  total 
system  is  designed  to  survive  this  situation.  The  armament  bus  uses  an  unusual  protocol  to  reduce  latency  of  time 
critical  messages  and  so  the  SMS  functions  are  kept  segregated  to  avoid  causing  problems  to  other  systems  not 
tolerant  of  this  protocol.  Global  data  and  certain  other  multiuser  high  rate  data  is  transferred  by  using  the  1 553 
broadcast  technique.  The  interbus  protocols  described  in  the  paper  are  able  to  support  interbus  broadcast. 

M.Burforci,  UK 

Has  the  demonstrator  rig  the  capability  to  insert  data  in  order  to  either  generate  errors  or  to  continue  the  simulated 
mission  in  a  formal,  self  documenting  dynamically  closed  loop  manner? 

Author’s  Reply 

Yes.  It  is  possible  to  dynamically  inject  faults  into  any  part  of  the  system  in  real  time  during  a  flight.  We  also  are 
able  to  record  the  operation  of  the  system  before,  during  and  after  the  injection  of  faults  or  the  occurrence  of  real 
defects.  This  data  can  be  analysed  after  the  flight  using  an  interactive  computer-based  system.  Manual  analysis 
would  be  almost  impossible  due  to  the  enormous  amount  of  data  produced  during  a  run. 


G.Hunt,  UK 

Has  your  use  of  the  1 553B  data  bus  in  the  Brough  Rig  work  shown  up  any  deficiencies  or  limitations  in  the  bus 
standards? 

Author's  Reply 

Yes.  Some  indication  would  be  useful  of  whether  Transmit-Receive  and  Broadcast  subaddress  should  be  overlayed 
or  segregated,  possibly  by  defining  CLASS  1  or  CLASS  II  terminals  for  overlayed  or  segregated  options.  The  content 
of  at  least  some  of  the  bits  in  the  R/T  fault  word  should  have  been  defined  and  not  left  to  the  R/T  implementor. 
Contiguity  is  not  specified  in  an  unambiguous  way  but  has  to  be  inferred  from  other  parameters.  It  needs  to  be 
specified  for  both  transmitters  and  receivers  in  such  a  way  that  the  transmission  characteristics  of  the  bus  cable  are 
allowed  for. 
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INTEGRATION  OF  IONIA  INTO  ADVANCED  HIGH  PERFORMANCE  FIGHTER  AIRCRAFT 


EDWARD  R.  CONRAD 

►  ENGINEERING  SPECIALIST,  COMM  AND  IFF  GROUP 

FORT  WORTH  DIVISION  OF  GENERAL  DYNAMICS  CORP. 
i  P,  0,  BOX  748,  MAIL  STATION  1347 

FORT  WORTH,  TEXAS,  USA  76101 

INTRODUCTION 

An  aircraft  Communications  Navigation  and  Identification  (CNI)  system  traditionally  consists  of  a 
number  of  independently  operating  "radios'*  each  providing  a  unique  communications,  navigation  aid  or  iden¬ 
tification  function.  Each  radio  was  probably  developed  autonomously  with  little  regard  for  any  of  the 
other  CNI  functions.  The  technology  used  in  the  circuitry  of  any  function  depends  upon  the  time  frame  in 
which  the  black  box  was  designed.  Thus,  the  circuitry  in  the  equipments  in  CNI  systems  may  run  the  gambit 
from  vacuum  tube  equipment  to  LSI.  Furthermore,  the  technology  of  the  function  Itself,  l.e. ,  modulation 
techniques  carrier  frequencies,  etc.  is  of  the  time  period  in  which  the  function  was  developed.  Consequently 
in  the  most  recent  CNI  equipments,  some  rather  outdated  techniques  are  performed  by  some  rather  sophisticated 
circuitry. 

The  modernization  of  military  CNI  is  deterred  by  two  factors.  First,  the  CNI  system,  unlike  a  radar 
or  a  display,  must  operate  with  an  outside  cooperating  station.  Second,  CNI  systems  not  only  perform  the 
command  and  control  function  for  the  military  mission  of  the  aircraft  but  also  are  required  for  the  regu¬ 
lation  of  flight  in  civilian  controlled  airspace.  Both  of  these  factors  mean  that  the  modernization  of  a 
function,  say  for  instance  a  change  in  modulation  technique  for  a  communications  system,  must  be  accom¬ 
plished  throughout  all  aircraft  and  a_l  ground  stations,  in  a  given  time  period.  Unless  such  a  change 
results  in  a  large  benefit,  the  economics  of  the  change  is  prohibitive. 

In  the  1950s,  CNI  equipments  were  Integrated  from  their  "blts-and-pleces”  status  Into  a  single  system. 

An  example  of  thia  is  the  AN/ASQ-19  CNI  systsa  developed  for  the  F-4  airplane.  However,  these  systems 
consisted  of  the  repackaging  of  existing  radios  Into  several  boxes  physically  tailored  to  fit  the  airplane 
and'  using  a  common  power  supply.  This  approach  eased  the  equipment  Installation  problem  but  did  little 
else  for  treating  CNI  as  a  systsa. 

In  the  1960s,  the  military  began  a  series  of  studies  on  a  Unified  CNI  (UCNI)  system.  This  concept 
changed  all  the  military  commu nice t Iona,  navigation  aids  and  identification  functions  so  that  they  would 
use  a  common  waveform  in  a  common  frequency  band.  The  technology  for  this  approach  is  sound  but  the  prob- 
lsns  of  transition  from  conventional  CNI  to  UCNI  are  practically  Insurmountable.  Furthermore,  unless  the 
transition  Included  civil  alrcrsft  control  facilities,  military  aircraft  would  still  be  required  to  carry 
some  conventional  CNI  when  operating  in  civilian  controlled  airspace. 

The  alternative  to  unifying  the  CNI  waveform  and  frequency  is  to  unify  the  CNI  equipment  Itself  and 
retain  the  present  waveforms  and  frequencies.  Through  several  studies,  this  approach  has  evolved  into 
the’  Integrated  CNI  avionics  (ICNIA)  presently  under  development  by  AFWAL  today.  Thl3  paper  examines  the 
Incorporation  of  such  a  system  into  modern  high  performance  fighter  aircraft. 

WHAT  IS  ICNIA? 

Any  CNI  function  can  be  reduced,  in  a  rather  simplified  manner,  to  three  elements: 

o  A  receiver-transmitter  o  A  signal  processor  o  A  data  processor 

A  block  diagram  of  such  a  function  is  shown  in  Figure  1.  In  the  receive  mode,  the  RF  waveform  is  received 
and  converted  to  baseband  in  the  receiver-transmitter.  The  baseband  signal  then  flows  to  the  signal  pro¬ 
cessor  where  it  is  converted  from  its  transmission  format  to  a  cordon  digital  format.  The  common  digital 
format  is  presented  to  the  data  processor  for  storage  and  for  distribution  to  the  aircraft  avionics  system. 

In  the  transmit  mode,  the  data  to  be  transmitted  is  gathered  from  the  aircraft  avionics  system  and  pro¬ 
cessed  into  a  digital  format  by  the  data  processor.  This  signal  is  passed  to  the  signal  processor  which 
converts  it  to  the  required  transmission  format  at  baseband  and  sends  it  to  the  receiver-transmitter.  Here 
the  baseband  signal  is  converted  to  the  transmission  frequency,  amplified  and  transmitted. 
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With  today's  technology  In  processors.  It  Is  possible  for  a  single  signal  processor  and  data 
processor  to  handle  all  CNI  functions.  Therefore,  by  Interfacing  several  receiver- 
transmitters  with  the  signal  processor  an  Integrated  CNI  system  can  be  realized.  Except  for  the  High 
Frequency  Communications  (HF  Comm)  function,  the  CNI  functions  operate  either  in  the  VHF,  UHF  or  t  Band 
portion  of  the  frequency  spectrum.  If  the  receiver-transmitters  are  made  up  of  svltchable  building  block 
components  which  ere  switched  under  Che  supervision  of  the  data  processor,  the  ICNIA  system  can  become 
adaptive.  The  data  processor  selects  the  CNI  functions  to  be  activated  at  any  point  in  the  mission.  If  one 
wf  the  t-feccl.Jkt-Lfai.aait ter  hollaing  tiocts  iailo  in  1  * btL.1 .  iQrt.A  t*n  tec.  tA Igur-c  It ’  lit  ly 

receiver-transmitter  components  so  that  only  the  lowest  priority  CNI  function  is  lost.  If  priorities 
change  during  the  mission,  the  data  processor  will  reconfigure  the  receiver-transmitter  components  to  re¬ 
flect  this  change. 

This  is  the  concept  being  developed  by  ICNIA.  An  overall  block  diagram  is  presented  In  Figure  2. 

The  CNI  functions  being  Incorporated  Into  ICNIA  Include: 

o  HF  Voice  Communications  o  TACAN 

o  VHF  Voice  Communications  with  Antijam  capability  o  ILS/VOR 

o  UHF  Voice  Communications  with  Antijam  capability  o  JTIDS 

o  IFF  transponder  o  GPS 

o  IFF  Interrogator  o  AFSATCOM 


ICNIA  offers  the  avionics  Integrator  three  advantages  over  present  CNI  equipments: 

o  A  unified  system  which  Is  readily  compatible  with  the  architecture  of  modern  aircraft 
avionics  suites. 

o  A  highly  reliable  CNI  system  due  to  its  ability  to  reconfigure  Itself  and  thereby  "repair” 
high  priority  functions. 

o  A  considerable  savings  in  CNI  space,  weight,  pover  and  cooling  requlxasmts. 

Furthermore,  It  attains  these  advantages  vlthout  Impacting  the  established  CNI  waveforms. 

ICNIA  INTEGRATION  INTO  AIRCRAFT 

The  historically  autonomous  nature  of  CNI  equipments  results  In  a  number  of  possibilities  for  Inte¬ 
gration  of  an  ICNIA  system  Into  an  airplane  avionics  suite.  These  possibilities  range  from  Incorporating 
many  ports  on  the  ICNIA  corresponding  to  the  ports  on  the  Individual  equipments  to  bringing  the  total 
ICNIA  I/O  across  a  multiplex  port  -  perhaps  evsn  a  fiber  optic  port.  The  selection  of  an  Interface  tech¬ 
nique  must  be  consistent  with  the  avionics  suite  of  the  host  aircraft. 

Obviously,  the  most  desirable  Interface  with  ICNIA  wuld  be  via  multiplex  bus  only.  However,  In 
older  non-multiplex  bus  aircraft  the  Implementation  of  such  a  technique  may  be  cost  prohibitive,  and  in 
some  cases  the  uature  of  the  I/O  signals  may  not  allow  them  to  be  readily  multiplexed.  Communications 
signals  are  normally  audio  for  voice  or  some  form  of  digital  data  for  data  links  (e.g.  JTIDS).  The  Navi¬ 
gation  Aids  signals  are  usually  synchro  and  meter  movement  signals  which  drive  aircraft  Instruments.  IFF 
I/O  signals  are  limited  to  control  signals.  In  the  case  of  transponders,  or  a  video  signal  which  is  mixed 
with  radar  video,  In  the  case  of  Interrogators.  Some  of  these  signals  can  easily  be  handled  in  a  digital 
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multiplex  format,  while  others  will  present  problems  in  certain  installations. 

To  illustrete  I  CM  A  Interface  with  elrcraft  two  types  of  evlonlcs  suites  will  be  considered.  The 
first  Is  en  aircraft  without  an  avionics  multiplex  interfece.  This  will  represent  the  older  aircraft  in 
service  todey.  The  second  will  show  an  aircraft  evlonlcs  suite  with  a  dual  multiplex  bus  interfece  such 
es  is  being  designed  today. 

Actually,  the  lntegretlon  of  ICNIA  into  non-multiplex  avionic  suites  is  the  more  difficult  of  the 
two  cases  stated  ebove.  The  Impact  on  this  cless  of  aircreft  is  higher  beceuse  very  few  atendards  existed 
for  Interfaces  between  subsystems  when  these  elrcreft  were  designed.  Therefore,  the  ICNIA  Interface  would 
require  teilorlng  for  each  type  of  aircreft.  However,  it  is  concelveble  that  by  the  time  ICNIA  becomes 
operetional,  the  older  elrcreft  will  have  been  updeted  to  a  multiplex  architecture.  Indeed,  it  would  be 
pleusible  that  ICNIA  would  be  retrofitted  es  part  of  en  evlonlcs  update  program.  This  situation  would 
allow  the  complete  redesign  of  the  evlonlcs  suite  to  a  multiplex  architecture  and  allow  the  retrofit  cost 
of  ICNIA  to  be  shared  with  other  emerging  systems. 

ICNIA  is  designed  to  eccomplish  the  majority  of  its  I/O  via  a  multiplex  bus.  The  exception  to  this 
rule  is  that  the  audio  I/O  will  be  analog.  Unfortunately,  the  non-multiplex  bus  airplene  cannot  use  the 
CNI  signal  outputs  on  the  multiplex  bus.  Consequently  an  ICNIA  Adaptor  is  necessary  to  Interface  the 
multiplex  bus  I/O  of  the  ICNIA  to  the  hardwired  CM  dlspley  and  control  Interface.  This  Interface  is 
shown  in  block  diagram  form  in  Figure  3.  The  ICMA  Adeptor  will  Interface  with  the  multiplex  bus  on  the 
ICNIA. 
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FIGURE  J.  ICNIA  INTECRATED  INTO  N0N-KULT1FLEX  AIRCRAFT 


The  functions  of  the  Adaptor  are  as  follows: 

o  The  passthrough  of  navigation  dete  between  the  GPS  function  and  the  Avionics  System. 

o  The  pessthrough  of  navigetion  deta  between  the  JTIDS  function  end  the  Avionics  System. 

o  The  collection  of  elrcraft  stete  vector  data  for  JTIDS  transmissions. 

o  The  formatting  of  JTIDS  dlspley  dete. 

o  The  dlgltel-to-analog  conversion  of  Nevlgetlon  Aid  dete  (TACAN,  ILS,  VOR)  for  dlspley  on  the 
analog  Instruments  (HSI,  ADI). 

o  The  ecceptance  end  passthrough  of  inltlallzetlon  deta  for  JTIDS  end  GPS. 

o  The  ecceptance  end  passthrough  of  stetus  monitoring  and  reporting  dete  for  ICNIA. 

o  If  required,  eccept  control  signals  of  various  formats  from  the  ICNIA  function  control  boxes 
and  pass  them  to  ICNIA  via  the  ICNIA  multiplex  bus. 

The  control  functions  mentioned  in  the  last  point  will  be  discussed  in  a  separate  section  of  this 
paper. 

The  lntegretlon  of  ICNIA  into  e  multiplex  interfeced  evlonlcs  suite  is  conslderebly  simpler.  Consider 
en  avionics  suite  architecture  shown  in  Figure  A.  This  is  e  two  multiplex  bus  system.  One  bus,  the  evlonlcs 
bus,  or  A  bus  handles  primarily  navigation  data  while  the  display  bus,  or  D  bus  handles  dlspley  dete. 

While  the  system  contains  many  new  avionics  subsystems,  those  of  interest  to  ICNIA  ere  en  Up  Front  Control 
(UFC),  a  Data  Transfer  Unit  (DTU),  a  Programmable  Dlspley  Generetor  (PDG)  and  two  Multi  Function  Displays 
(MFD).  The  Central  Computer  has  two  independent  multiplex  ports  and  is  the  bus  controller  for  both  buses. 
The  UFC  is  e  control  which  provides  pilot  interface  with  the  Central  Computer  end  control  of  the  CNI  equip¬ 
ment.  The  OTU  is  e  unit  which  accepts  e  date  storege  device  (such  es  PROMS)  end,  from  this  device,  pro¬ 
vides  mission  data  (e.g.  waypoints)  end  initialization  data  to  tue  various  subsystems  (e.g.  JTIDS).  Note 
that  data  can  be  passed  through  the  central  computer  to  the  equlpmenta  interfaced  with  the  dlspley  bus. 

The  PDG  end  MFDs  form  a  versatile  display  system. 
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FICJRZ  <•  ADVANCED  AIRCRAFT  AVIONICS  ARCHITECTURE 


The  integration  of  ICNIA  into  this  avionic  architecture  is  more  straight  forward  than  into  the  non- 
multiplex  airplane.  There  are  two  reasons  for  this:  (1)  this  avionics  suite  has  the  UFC  which  can  control 
the  ICNIA  functions  via  the  A  bus  and  (2)  the  display  system  is  more  versatile. 

The  ICNIA  integrated  into  the  multiplex  airplane  is  shown  in  Figure  5.  The  only  non-Mux  interfaces 
are  with  the  audio,  and  a  digital-to-analog  converter  which  drives  the  analog  Horizontal  Situation  Indica¬ 
tor  (HSI)  and  Attitude  Director  Indicator  (ADI)  to  display  TACAN,  ILS  and  VOR  data.  Actually,  digitized 
audio  could  be  transmitted  via  one  of  the  buses  in  a  16Kbps  Continually  Variable  Slope  Delta  Modulation 
(CVSD)  format;  however,  this  would  require  the  design  of  a  digital  audio  distribution  system  (Intercom). 


riCURI  5,  ICNIA  INTEGRATION  INTO  ADVANCED  AIRCRAFT 


The  signal  flow  on  the  A  bus  includes: 

o  Navigation  data  to  and  from  CPS  o  Control  functions 

o  Navigation  data  to  and  from  JTIDS  o  Initialization  data 

The  D  bus  carries  CNI  data  to  and  from  the  PDG  for  display  on  one  of  the  MFDs.  It  will  carry  display 
mode  Information  from  the  MFD  to  JTIDS. 

CONTROL  AND  DISPLAY 

The  aircraft  crew  interfaces  with  the  ICNIA  by  three  methods:  (1)  controls  which  determine  the  mode, 
frequency,  ate.  of  the  CNI  functions,  (2)  displays  which  are  a  visual  representation  of  tha  information 
derived  from  the  CNI  functions,  and  (3)  audio  from  the  voice  receivers  and  to  the  voice  transmitters,  plus 
tha  audio  Identification  of  the  navigation  aid  beacons.  In  the  ICNIA  design,  tha  control  and  display 
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signals  are  Interfaced  via  a  multiplex  bus  while  each  audio  signal  has  Its  own  port.  The  audio  will 
Interface  directly  with  the  host  aircraft  in  ter  cob.  However,  the  control  and  display  functions  will  re¬ 
quire  some  adaptation  in  the  non-multiplex  aircraft  while  Interfacing  directly  In  the  multiplex  aircraft. 

To  provide  ICNIA  control  In  the  non-multiplex  airplane  three  approaches  are  viable: 

o  Retain  the  present  CNI  control  panels.  Convert  the  control  signals  to  Mux  format  In  the  ICNIA 
adaptor . 

o  Retain  the  present  CNI  control  panels  In  their  physical  form  but  convert  the  Internal  circuitry 
to  a  Mix  terminal. 

o  Replace  the  present  CNI  control  panels  with  an  Integrated  control  panel  with  a  Mux  I/O. 

Uith  the  first  option,  the  control  panels  are  retained.  These  panels  have  a  variety  of  I/O  formats 
ranging  from  discretes  to  tailored  serial  streams.  Each  panel  is  Interfaced  to  an  Individual  port  on  the 
ICNIA  adaptor.  The  Adaptor  converts  the  control  panel  signals  to  a  Mux  block  format  and  transmits  It  to 
the  ICNIA  via  the  Mux.  Feedback  signals,  where  used,  are  sent  from  ICNIA  to  the  Adaptor  via  Mux,  converted 
Into  the  control  panel  format  and  sent  to  the  panel  via  Its  Interface  port.  Such  an  architecture  Is  shown 
In  Figure  6. 
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FIGURE  6  RETAINED  CONTROL  RCXIS 


FIGURE  7  CONTROLS  UITH  MULTIPLEX  TERMINALS 


FIGURE  I  ICNIA  CONTROLLED  IT  UPC 


Uith  the  second  option,  the  physical  configuration  of  the  control  panels  la  unchanged.  The  internal 
circuitry  Is  changed  so  that  It  formats  control  information  In  the  ICNIA  Mux  format  and  sends  It  directly 
to  the  ICNIA  via  the  Mux.  This  arrangement  Is  shown  In  Figure  7.  While  these  control  panels  would 
closely  resemble  thalr  Individual  equipment  counterparts,  the  circuitry  would  change  completely  to  lncluda 
a  mux  terminal  and  associated  logic. 


Tha  third  option  would  remove  all  CNI  control  panels  from  the  cockpit  end  replaca  tha  with  e  central 
control  which  communlcatas  with  tha  ICNIA  via  Its  Mux.  All  CNI  functions  ara  than  controlled  from  a  single 
cockpit  location.  Tha  UFC  used  In  the  multiplex  architecture  would  fulfill  tha  requ  Irma  ant  for  a  central 
CNI  control.  The  UFC/ICNIA  control  archltectura  Is  shown  In  Figure  8. 


JTIDS  requires  soma  form  of  situation  display.  Tha  mannar  of  lnplmientetion  of  this  display  Is 
dependent  on  tha  airplane  display  system.  If  no  existing  display  Is  available  to  time  share  with  JTIDS, 
a  naw  dedicated  display  would  ba  required. 
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ANTENNAS 

The  present  trend  In  tactical  fighter  aircraft  tovard  smaller  airframes  and  a  greater  number  of  elec¬ 
tronic  systems  has  resulted  in  an  antenna  location  problem  of  a  major  magnitude.  Simply  stated,  there 
Just  Isn't  enough  room  for  ell  the  antennas.  The  F-16  antenna  locations  shown  In  Figure  9  Illustrate  this. 
This  problem  is  aggravated  by  the  added  functions  of  ICNIA.  Each  ICNIA  function  cannot  have  its  own  an¬ 
tenna  system.  Some  functions  must  share  antennas.  The  L-Band  system,  TACAN,  IFF  end  JTIDS,  being 
low-duty-cycle,  pulse  systems,  can  share  the  same  antenna  system  if  the  proper  transmitter-receiver  coordin¬ 
ation  of  these  functions  is  included  in  the  ICHIA.  Other  comon  frequency  antenna  integrations  would  be 
more  difficult,  such  as  UHF  voica/glldeslope/SATCOM  and  VHF  voice/locallzer/VOR.  These  integrations  are 
more  difficult  because  of  transnitter  high-duty  cycles  and  antenna  polarizations  end  are  considered  to  be 
beyond  the  scope  of  this  paper.  However,  It  Is  recommended  that  an  antenna  Integration  program  be  im¬ 
plemented  for  these  functions  to  alleviate  the  antenna  location  problem. 


FIGURE  9.  F-16  ANTE. ‘IN A  LOCATIONS 


Tha  HF  function  presents  a  unique  antenna  problem.  HF  antennas  on  small  aircraft  ara  usually  In  the 
fora  of  a  notch  in  the  vertical  fin  which  excites  tha  entire  airframe.  The  feedpolnt  impedance  of  this 
notch  cannot  remain  constant  over  the  nearly  four  octaves  of  the  spectrum  covered  by  HF.  Therefore,  an 
antenna  couplar  Is  required  to  present  a  constant  load  to  the  HF  transmitter.  The  coupler  must  be  located 
near  the  antenna  faed  and  must  be  tailored  to  the  particular  airframe.  It  may  also  require  frequency 
Information  from  the  ICNIA.  Tha  coupler  such  as  that  designed  for  the  F-lll  would  operate  with  ICHIA, 
provided  the  ICNIA  adaptor  furnishes  frequency  information  to  the  coupler. 

SUMMARY  AND  CONCLUSIONS 

^  /  '■) 

NThe  use  of  ICNIA  will  significantly  improve  the  Avionics  Suites  of  military  aircraft.  -The  advantages 
of  ICNIA  include: 

o  Reduction  in  spaca,  weight,  power  and  cooling  requirements 
o  Increase  in  reliability  end  maintainability^ 
o  Decrease  in^tlfe  Cycl 

6  Ease  of  integration  into  an  Avionics. Suite  via  a  multiplex  bus  .  £.v  « 

j  r  y 

o  Reconfigurability, 

However, ^50  take  advantage  of  these  features,  certain  design  guidelines  should  be  followed.  The 
basic  guideline  is  that  the  elrfraaer  should  control  tha  integration  of  any  subsystem  into  his  Avionics 
Suite.  This  implies  that  the  ICNIA  interface  software,  and  possibly  some  of  the  hardware,  must  ba  in 
accordance  with  tha  integration  philosophies  of  the  boat  platform.  These  philosophies  will  very  from  one 
host  platform  to  the  other.  General  Dynamics  has  an  integration  and  partitioning  concept  which  has  func¬ 
tioned  exceptionally  well  on  the  F-16.  -Simply  »tatadj>ych  subsystem  should  perform  its  entire  task  and 
the  interfaces  between  subsystems  should  be  as  simple  es  possible.  This  concept  has  three  major  advantages: 
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,6  Changes  Co  one  subsystem  are  transparent  to  other  subsystems  and  do  not  result  In  changes 
being  required  in  other  subeysteas  when  one  subsystea  is  changed. 
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The  integration  of  a  new  subsystea  Into  the^AsTionics  /86ite  is  not  difficult  since  a  new 
system  doee  not  require  unique  support  of  other  subsystems.  <d 

Fault  isolation  Is  simple  since  each  subsystem  perforae  an  entire  task.  _ 

v 


General  Dynamics  recommends  that  these  characteristics  be  included  in  the  ICNIA  to  be  installed  on 
the  F-16.  However,  other  alrfraaers  may  have  other  interface  requirements.  Thus,  a  platfofm  unique  inter¬ 
face  may  be  needed  in  ICNIA  in  order  to  satisfy  the  requirements  of  each  using  aircraft.  This  may  be  in 
the  form  of  either  a  platform  unique  software  module  or  a  unique  hardware  Interface  module  along  with  the 
software  module.  The  JTIDS  Class  2  Terminal,  for  example,  has  a  platform  unique  I/O  Adaptor  which  contains 
the  hardware  to  match  audio  Impedances,  instrument  drive  requirements,  etc.  along  with  the  interface  soft¬ 
ware  which  performs  the  I/O  via  the  platform  data  bus. 


A  recent  trend  in  new  avionic  systems  is  to  provide  "by-product  functions".  These  are  functions 
which  are  not  the  primary  purpose  of  the  equipment  but  rather  a  by-product  of  the  function  performed  by 
the  equipment.  The  use  of  theee  by-product  functions  should  not  be  forced  upon  the  alrframer.  Each  air- 
framer  has  his  philosophy  on  how  best  to  fulfill  the  requirements  of  his  aircraft  and  how  well  the 
by-product  function  will  aid  the  aircraft  mission. 


One  by-product  which  has  been  appearing  in  the  equipments  which  perform  a  primary  or  by-product  navi¬ 
gation  function  is  the  inclusion  of  a  Kalman  filter  to  mix  navigation  data  from  several  sources  to  obtain 
a  best  estimate  position.  Since  navigation  data  is  usually  filtered  by  the  aircraft,  this  may  result  in 
two  Kalman  filters  being  mechanized  in  the  avionics  suite.  This  leads  to  a  rather  precarious  situation 
in  that  the  two  filters  may  exchange  correlated  error  information.  If  this  happens  one  or  both  of  the 
filters  could  cause  errors  and  may  become  unstable.  General  Dynamics  feels  chat  the  processing  of  navi¬ 
gation  data  from  several  sources  is  a  systems  function  and  should  reside  in  the  central  processor.  How¬ 
ever,  other  aircraft  systems  integrators  may  not  agree.  Therefore,  General  Dynamics  recommends  that  the 
architecture  of  ICNIA  be  such  that  the  use  of  a  Kalman  filter  in  ICNIA  can  be  at  the  option  of  the  avionics 
systems  integrator. 

Since  this  paper  has  addreseed  generic  aircraft  installations,  no  discussion  of  the  physical  character¬ 
istics  has  been  included.  Because  of  the  odd  shapes  available  in  fighter  aircraft  equipment  bays,  ICNIA 
should  be  made  up  of  standard  sized  modules  which  can  be  used  as  building  blocks  to  form  odd  sized  LRUs. 
Looking  at  future  aircraft,  a  wholly  modular  avionics  suite  made  of  card  racke  with  a  few  types  of  standard 
modules  seems  probable.  The  VHSIC  and  PAVE  PILLAR  projects  support  such  a  concept.  The  ICNIA  design  will 
fit  these  advanced  concepts.  The  Very  High  Speed  Integrated  Circuits  being  developed  by  the  Government 
will  result  in  a  chip  set  which  will  form  a  KIL-STD-1750  proceesor.  This  VHSIC  chip  set  ehould  be  directly 
applicable  to  the  elgnal  processor  and  the  data  proceesor. 


The  PAVE  PILLAR  project  is  preeently  studying  the  architecture  of  advanced  avionic  syetems.  ICNIA  is 
actually  a  part  of  PAVE  PIJLAR  and  will  be  blended  into  it  in  the  future.  ICNIA,  having  the  versatile 
multiplex  I/O  that  it  does,  will  integrate  into  either  the  eingle  or  hierarchical  bus  structure  being 
advanced  today. 

Finally,  ICNIA  conforms  with  the  avionic  eyetan  concepts  of  the  future.  This  concept  embraces  the 
sensor  (receiver-transmitter),  signal  processor,  data  proceeeor  structure  est  forth  previously  in  this 
paper.  Since  all  avionic  functions  can  be  modeled  to  this  structure  and  since  a  etandard  processor  is 
forthcoming,  all  functions  of  an  avionice  system  can  coneiet  of  etandard  processors  and  epeclallzad  sensors, 
mien  this  is  accomplished,  the  LRUs  of  today  can  be  replaced  with  card  racks  coneletlng  of  standard  pro¬ 
cessor  carde  and  special  sensor  cards.  As  such,  the  entire  avionics  suite  will  be  composed  of  racks  of 
standard  cards  plus  the  special  cards.  The  Impact  of  thle  concept  on  systems  deelgn,  maintenance  and 
logistics  challenges  the  imagination. 
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DISCUSSION 


R, Davies,  Ca 

The  list  of  avionics  CNI  subsystems  10  be  integrated  into  ICNIA  included  ILS  and  in  general  covered  frequencies 
between  2  MHz  and  2  GHz.  As  ILS  is  only  “protected”  by  ICAO  until  1 995,  should  not  1CN1A  include  MLS  inter¬ 
faces  for  5  GHz  azimuth  and  elevation  information  in  this  regard?  The  first  MLS  civil  certified  system  easily  fed 
signals  into  a  “DDM”  type  ILS  receiver  through  a  ‘C’  band  antenna  and  converter.  New  TRSB  MLS,  as  covered  by 
ICAO  “SARPS”,  may  be  difficult  to  handle  and  ICAO  appears  to  pay  no  regard  to  MIL  Spec  1 553B  data  bus 
requirements. 

Author’s  Reply  -A 

The  functions  to  be  included  in  ICNIA  are  designated  by  the  government  sponsoring  agency.  It  could  well  include 
MLS  at  a  later  date.  My  personal  opinion  is  that  MLS  should  be  included.  Processing  of  the  MLS  signals  should 
offer  no  problem. 


W.RJohnson,  US 

■  How  are  receiver/transmitters  operating  on  different  frequency  ranges  (VHF,  UHF,  SHF,  etc.)  applicable  to 
reassignment? 

Author’s  Reply 

The  receiver/transmitters  are  divided  into  three  types:  L-band,  VHF/UHF  and  HF.  Therefore  a  failed  type  must  be 
replaced  by  the  same  type,  e.g.  L-band  for  L-band. 
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SUMMARY 

/  — ? 

The/>pptimization  of  an  air-to-ground  weapon  inventory  must  investigate  the  trade¬ 
off  between  the  effectiveness  of  the  weapons  and  the  vulnerability  of  the  delivery  air¬ 
craft  to  opposing  ground  defences  while  flying  the  mission  profile  required  by  the,, 
weapon.  The  Directorate  of  Air  Operational  Research  within  the  Canadian  DepM=tmernf,of 
National  Defence  has  developed  a  computerized  technique  for  describing  and  constructing 
air-to-ground  mission  profiles  in  relation  to  actual  terrain.  The  aim  was  to  develop  a 
profile  construction  system  that  permits  the  user  to  accurately  but  concisely  direct  the 
construction  process.  The  technique  relies  on  computer  graphics  to  assist  the  user  in 
creating  realistic  attack  profiles.  The  system  employs  a  data  base  of  digitized  central 
European  terrain  to  produce  perspective  terrain  image  snapshots  at  key  positions  in  the 
profile. 

Post  analysis  of  the  exposure  history  of  a  given  profile  w-iil  allovjj'a  reasonable 
assessment  of  the  comparative  survivability  of  an  aircraft  having  to  deliver  weapon 
type  A  versus  its  survivability  when  delivering  weapon  type  B.  Although  designed  for 
use  in  weapon  mix  determinations  for  the  Canadian  Forces,  this  analysis  tool  may  have 
useful  applications  in  both  aircraft  design  and  air-to-ground  weapon  design  for  low  level 
ground  attack  missions.  •<,- 


INTRODUCTION 

The  Canadian  Forces  are  in  the  process  of  acquiring  a  new  fleet  of  138  CF-18A  fight¬ 
er  aircraft.  The  purchase  of  an  updated  inventory  of  air-to-ground  weapons  for  use  with 
the  CF-18A  is  being  considered.  The  Directorate  of  Air  Operational  Research  has  been 
tasked  to  develop  analytic  tools  to  assist  in  the  selection  process. 

The  primary  trade-off  against  the  destructive  effectiveness  of  an  air-to-ground  wea¬ 
pon  is  the  vulnerability  ol  the  aircraft  to  ground  defences  while  flying  the  required  wea¬ 
pon  delivery  profile.  The  models  described  in  this  paper  were  developed  to  assist  in  the 
assessment  of  the  relative  vulnerability  of  specific  delivery  tactics. 

Aircraft  vulnerability  at  low  altitude  is  directly  dependent  on  the  terrain.  If 
terrain  is  simulated  or  characterized,  and  analysis  proceeds  on  this  basis,  then  the 
results  would  involve  uncertainties  that  would  be  impossible  to  quantify.  Consequently 
the  decision  was  made  at  an  early  stage  to  employ  real  terrain  (digitized  and  supplied 
courtesy  of  the  Defense  Mapping  Agency  in  the  United  States) . 

The  first  step  in  the  modelling  process  is  to  develop  a  system  for  describing  and 
constructing  realistic  ground  attack  flight  profiles  in  relation  to  the  terrain.  A 
machine-readable  record  of  the  profile  is  the  end  product.  There  is  a  complete  spectrum 
of  possible  modelling  approaches  to  accomplish  this  task.  Section  1  describes  the  de¬ 
tails  of  the  model  that  was  developed  and  the  rationale  behind  the  selected  approach. 

The  model  is  entitled  GAPS  II,  an  acronym  for  Ground  Attack  Profile  Selector  program 
(version  II) . 

The  next  step  towards  assessing  aircraft  vulnerability  is  the  adoption  of  intervisi¬ 
bility  algorithm?  so  that  the  existence  or  non-existence  a  line-of-sight  between  a  ground 
defensive  position  and  the  aircraft  can  be  determined.  The  end  product  of  the  intervisi¬ 
bility  evaluation  is  an  "exposure  history"  -  a  tabulation  of  all  key  parameters,  from 
the  point  of  view  of  the  defensive  position,  that  will  affect  the  ability  of  the  air 
defence  equipment  to  engage  the  aircraft.  Sections  2  and  3  of  this  paper  describe  the 
modelling  efforts  that  bring  the  process  to  the  "exposure  history"  stage. 

Future  work  on  this  project  will  be  directed  towards  a  numerical  evaluation  algorithm 
for  the  relative  vulnerability  assessment  of  different  exposure  histories.  The  term 
"relative"  in  the  proceeding  sentence  is  important.  Vulnerability  in  absolute  terms  - 
in  the  form  of  a  probability  of  kill  or  an  attrition  rate  -  is  considerably  more  diffi¬ 
cult  to  model  with  an  acceptable  level  of  accuracy.  Since  the  project's  objective  is  to 
compare  different  air-to-ground  weapons  to  each  other,  then  a  less  complex  comparative 
methodology  will  be  sufficient. 
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1.  THE  GROUND  ATTACK  PROFILE  SELECTOR  (GAPS  II)  PROGRAM 

The  development  objective  of  the  GAPS  IX  system  was  to  devise  a  method  of  creating 
a.id  ietOiding  a  ^eallotic  yiOuiid  attack  pj.Olj.le  1..  ..elation  to  actual  terrain .  The  Con¬ 
struction  process  should  be  accurate  but  concise;  a  process  that  a  person  with  fighter 
pilot  experience  could  feel  comfortable  with,  so  that  maximum  realism  can  be  transmitted 
to  the  resulting  profile.  Accuracy  and  conciseness  are  in  general  conflicting  objectives, 
so  careful  selection  of  the  modelling  approach  is  necessary. 

One  approach  would  be  to  directly  simulate  the  aircraft  aerodynamics,  accepting 
stick,  throttle,  etc.  inputs  and  integrating  the  equations  of  motion  to  determine  future 
positions  for  the  aircraft.  This  method  would  produce  very  realistic  profiles.  However 
it  would  involve  a  heavy  computational  load  and  a  large  data  base  for  every  aircraft  to 
be  simulated,  not  to  mention  a  considerable  development  effort  for  the  software. 

Another  approach  would  be  to  forego  all  aircraft-related  parameters  entirely  and 
simply  specify  directly  a  path  of  (X,Y,Z)  positions  as  a  function  of  time  to  be  the  de¬ 
sired  profile.  This  method  permits  accurate  location  of  the  profile  in  relation  to  the 
terrain.  However,  it  could  easily  and  unknowingly  produce  results  that  imply  manoeuvres 
that  are  in  fact  outside  tuc  capability  cl  tile  airframe  to  generate.  Also,  the  construc¬ 
tion  process  would  be  very  tedious  for  all  but  short  profiles. 

The  two  approaches  described  above  represent  opposite  ends  of  the  modelling  spectrum. 

The  approach  that  was  selected  for  GAPS  II  lies  between  these  two  extremes,  and  is  des¬ 
cribed  dj  follows. 

A  profile  is  defined  by  a  series  of  flight  segments .  The  final  position  and  veloc¬ 
ity  vectors  of  a  segment  are  identically  the  initial  vectors  for  the  next  segment.  Four 
parameters  define  the  segment.  The  first  is  the  linear  acceleration.  It  always  acts 
in  the  direction  of  the  instantaneous  velocity  vector  to  produce  speed  changes.  The  sec¬ 
ond  parameter  is  lateral  acceleration,  which  always  acts  perpendicularly  to  the  instantan¬ 
eous  velocity  vector.  Lateral  acceleration  defines  the  aircraft  turn  rate.  Both  of  these 
accelerations  have  a  constant  magnitude  during  the  segment.  The  third  parameter  is  an 
angle,  defining  the  plane  on  which  the  lateral  acceleration  will  take  place.  The  fourth 
is  the  segment  duration  time. 

The  above  four  parameters  are  sufficient  to  define  a  unique  flight  segment.  The 
solution  "f  I  fur  Ctjus*  It'lS  t r  nttitn  i*  CT-isi  'rf  aid  f  ^*r  sr?  a  i  I"  r  ■  -vai-5  if  gravity  ft 
removed  from  the  problem.  This  assumption  not  only  simplifies  the  mathematics,  but  also 
makes  it  easier  for  the  flight  profile  constructor  to  guide  the  aircraft  across  the  ter¬ 
rain.  With  gravity  removed  there  are  no  extraneous  forces  acting  on  the  two  specified 
acceleration  values. 

The  locus  of  points  described  by  the  aircraft  during  a  single  flight  segment  is  two- 
dimensional.  The  lateral  acceleration  parameter  acts  in  a  plane  whose  orientation  is 
specified  by  the  third  segment  parameter,  which  is  called  the  "bank"  angle.  Thi3  angle 
is  defined  in  relation  to  the  aircraft  velocity  vector  at  the  beginning  of  the  segment 
and  the  positive  Z  (vertical)  axis.  The  combination  of  lateral  acceleration  and  "bank" 
angle  relates  directly  to  the  way  an  aircraft  will  roll  and  then  initiate  a  positive 
g-load  to  conduct  a  turn.  The  actual  bank  angle  on  a  real  aircraft  performing  the  man- 
ouevre  would  be  slightly  different  since  the  real  aircraft  would  also  have  to  deal  with 
gravity  -  hence  the  quotation  marks. 

Appendix  A  details  the  mathematical  solution  to  the  equations  of  motion  summarized 
from  Ref.  (1) .  Given  the  position  and  velocity  vectors  at  the  beginning  of  the  flight  seg¬ 
ment  and  the  linear  acceleration,  lateral  acceleration  and  "bank"  angle  values,  one  can 
directly  calculate  the  position  and  velocity  vectors  at  any  subsequent  point  in  time. 

The  segment  is  terminated  at  a  given  time.  This  time  may  be  specified  directly  or 
L*  msy  be  itt&Lied  by  fin  bthtr  ifiwUwl, 

acquired,  altitude  reached,  heading  acquired  or  climb  angle  attained.  Some  of  these 
termination  variables  can  be  directly  converted  to  time  (e.g.  distance  or  speed).  For 
the  remaining  variables  it  is  necessary  to  step  through  time  in  short  intervals  and 
identify  the  segment  duration  time  iteratively. 

The  mechanism  by  which  the  ground  attack  profile  is  constructed  has  now  been  laid 
down.  This  mechanism  must  now  be  encased  in  an  interactive,  automated  framework  that 
will  enable  accurate  and  efficient  construction  of  the  profile  in  relation  to  the  terrain. 

It  was  recognized  at  an  early  stage  in  the  project  that  the  assistance  of  computer 
graphics  would  be  essential  in  developing  an  efficient  system.  Production  of  a  perspec¬ 
tive  snapshot  of  the  terrain  in  front  of  the  aircraft,  as  it  would  be  viewed  from  the 
cockpit  at  that  instant,  would  provide  instant  feedback  to  the  profile  constructor.  He 
quickly  can  verify  that  a  selected  segment  in  fact  produced  the  desired  result.  Accuracy 
is  enhanced  and  maximum  realism  can  be  passed  on  to  the  constructed  profile.  Consequent¬ 
ly,  a  Tektronix  4054  Graphics  system  was  acquired.  This  is  a  desktop  computer,  pro¬ 
grammable  in  BASIC,  with  a  high  resolution  CRT  (storage  scope  as  opposed  to  raster-scan) . 

Maximum  memory  (64K  bytes)  and  a  flexible  disk  drive  are  required  options.  The  GAPS  II 
program  is  written  in  BASIC  for  this  hardware  system. 

Before  progressing  further,  a  description  is  given  of  the  terrain  data  base  and 
its  application  with  GAPS  II.  The  Defense  Mapping  Agency  (USA)  product  used  covers  the 
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region  illustrated  in  Figure  1:  49  to  51  degrees  north  and  10  to  14  degrees  east. 

This  portion  of  central  Europe  was  digitized  on  a  grid  every  3  seconds  of  arc  in  both 
latitude  and  longitude.  Elevations  are  recorded  to  the  nearest  3  meters. 


For  use  in  GAPS  II,  it  was  found  that  a  3  second  by  3  second  grid  produced  too  dense 

a  terrain  image,  so  the  data  was  thinned  to  every  6  seconds  in  both  latitude  and  longitude 

To  facilitate  handling  of  the  data  on  flexible  disks,  it  was  subdivided  into  20  minute  by 
2G  .[tL.iutc.  Llowks  us  -l ii  i  .Lvjuite  1.  bud,  blviCk  CoLtaxfts  4uv)Uu  elevatxOns.  xhe 

data  within  each  block  is  stored  in  duplicate,  so  that  it  can  be  directly  accessed  in 

records  of  constant  latitude  or  records  of  constant  longitude. 

Production  of  a  "snapshot"  of  the  terrain  from  the  aircraft's  position  is  accompli¬ 
shed  by  drawing  strings  of  elevations  from  the  terrain  data  base  and  projecting  them  appro 
priately  onto  the  graphics  screen  in  a  checkerboard  pattern.  To  simplify  the  projection 
calculations  and  to  be  consistent  with  the  conciseness  mandate  of  the  profile  construction 
system,  a  "flat  earth"  assumption  was  made.  The  terrain  data  is  projected  onto  a  rectan¬ 
gular  grid  with  longitudinal  compression  based  on  the  cosine  of  the  mean  data  latitude 
(50°) .  Note  that  for  the  purposes  of  constructing  a  flight  profile  in  relation  to  terrain 
the  Sligfrt  cafvatiiFfe  oi  bcth  th=  teirain  sM  the  profile  tutt  long  Jietsr.se*  Is  net  f.slly 
relevant.  It  is  the  short  range  relationship  between  aircraft  and  terrain  that  is  of  sig¬ 
nificance.  However,  for  the  purposes  of  assessing  exposure  of  the  aircraft  to  ground 
defences  over  moderate  to  long  ranges,  the  earth's  curvature  is  significant.  Hence  suit¬ 
able  corrections  for  earth's  curvature  are  made  at  that  stage. 

Fxg ult  2  t'ltot.its  ci  ac*iripit  uf  tlie  terXdxn  xlt a^er^  that  GA1 5  II  wx  11  produce.  The 
6  second  by  6  second  grid  projects  to  rectangles  approximately  185  m  north-south  by  119  m 
east-west.  Not ,  that  those  edges  or  portions  thereof  that  are  hidden  by  intervening  fore- 
grr*J  tsMSir  -SR  In  (set  the  altjtcitte  tha*  intermit**  Wti*.  vis¬ 

ible  and  which  are  masked  constitutes  the  majority  of  the  image  rendering  software. 
Appendix  B  1  ays  out  the  projection  equations  and  describes  the  terrain  masking  algorithm 
in  detail. 

Vhe  GAPS  II  program  consists  of  over  1300  lines  of  BASIC  code.  The  software  is 
modularized  to  take  advantage  of  the  user-detmabie  key  (UDK)  feature  of  the  machine. 

Each  of  the  20  UDKs,  when  selected,  executes  a  routine  to  accomplish  a  specific  task. 

For  example,  one  UDK  begins  construction  of  a  new  profile  segment.  Another  key  will  pro- 
tre  ttFiain  image  as  vi«eJ  At  the  of  ehe  EAueene  segment,  tlhet  v&  will 

list  sets  of  relevant  parameter  values  for  reference,  or  allow  one  of  the  four  segment¬ 
defining  parameters  to  be  refined.  Other  utility  routines  wills  permit  the  viewport  to 
be  changed;  allow  the  terrain  disk  to  be  changed;  enable  the  user  to  step  back  in  time  by 
deleting  any  number  of  the  most  recent  segments;  note  the  weapon  release  time;  terminate 
the  profile  construction;  and  even  change  the  hardware  character  size  being  used.  Note 
from  Figure  2  that  the  left  har.d  portion  of  the  screen  is  reserved  for  text.  This  modular 
ized  software  approach  allows  the  user  to  define  the  execution  stream  as  the  profile  con¬ 
struction  proceeds.  One  is  often  refining  flight  segment  parameters  to  produce  a  precise 
manoeuvre,  so  this  approach  suits  the  "hit  and  miss"  nature  of  the  construction  process. 


FIGURE  1 

DIGITAL  TERRAIN  CURRENTLY  AVAILABLE  TO  GAPS  II 
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Observe  also  from  Figure  2  that  there  are  several  objects  superimposed  upon  the 
terrain  image.  The  purpose  of  these  objects  is  twofold.  First,  they  can  be  located  at 
selected  geographic  positions  as  landmarks,  to  be  used  as  navigation  aids.  Secondly, 
they  can  be  drawn  to  represent  the  target  objects  of  the  air-to-ground  mission.  Also 
presented  on  the  image  in  Figure  2  is  a  horizon  reference  line  (dashed  line) ,  a  velocity 
vector  indicator  (cross  "+")  and  a  bomb-sight  (2  mil  and  50  mil  concentric  circles).  Co¬ 
ordination  of  the  above  visual  cues  permits  accurate  alignment  of  the  aircraft  during 
manoeuvres  leading  up  to  the  weapon  release  point. 

The  image  depicted  in  Figure  2  will  take  of  the  order  of  a  minute  or  two  to  produce 
on  the  Tektronix  hardware.  The  machine  is  not  capable  of  producing  real  time  imagery  and 
GAPS  II  is  not  designed  to  interact  in  real  time,  hence  it  should  be  emphasized  that  GAPS 
II  is  not  a  flight  simulator.  The  graphic  imagery  is  produced  simply  as  a  snapshot  to 
verify  the  conditions  at  the  end  of  any  segment  within  the  flight  profile.  For  the  pur¬ 
poses  of  demonstrating  the  GAPS  II  system,  however,  a  temporary  modification  w^.s  made 
that  allowed  the  program  to  automatically  step  through  a  pre-constructed  profile  and  take 
hard-copy  reproductions  of  these  images  at  shcrt  time  increments  during  the  profile.  The 
resulting  stack  of  paper  was  animated  into  a  one  minute  film  clip  by  the  Canadian  Forces 
photo  unit. 

A  transportable  and  complete  record  of  the  flight  profile  must  be  the  end  product 
from  GAPS  II.  Recorded  for  each  segment  of  the  profile  are:  the  position  and  velocity 
vectors  at  the  segment  start  and  end  points;  the  linear  acceleration,  lateral  acceleration 
and  "bank"  angle  parameter  values  that  apply  during  the  flight  segment;  and  the  time  at 
the  start  and  end  points.  Also  recorded  are  necessary  global  parameter  values  such  as 
the  latitude  and  longitude  of  the  profile  start  point  and  the  time  of  weapon  release. 

Along  with  this  data  file  goes  a  short  software  routine  called  ENDPOINT,  which  automates 
the  equations  in  Appendix  A.  This  routine  permits  the  above  data  file  to  be  interpolated, 
so  that  the  position  and  velocity  vector  at  any  point  in  time  during  the  profile  can  be 
calculated.  This  format  for  the  GAPS  II  end  product  was  considered  more  practical  than 
a  length  nist oi,  sf  position  and  velocity  at  fine  time  intervals.  oRiS  11  is  documented 
in  detail  in  Ref.  (2) . 


FIGURE  2 

SAMPLE  OF  GAPS  II  IMAGERY 


ASSESSMENT  OF  INTERVISIBILITY 


The  GAPS  II  model  produces  a  flight  profile  in  relation  to  the  digital  terrain. 

The  next  step  is  to  determine  how  exposed  this  profile  would  be  to  selected  defensive 
positions . 

Consider  a  piece  of  air  defence  equipment  at  a  specific  geographic  position  and 
sitting  on  the  terrain.  The  sensing  component  (e.g.  eyeball,  antenna,  etc.)  is  located 
at  some  height  above  the  ground.  The  first  step  in  the  exposure  assessment  process  is 
to  develop  a  method  of  determining,  at  any  point  along  the  flight  profile,  whether  or 
not  a  line  of  sight  exists  between  the  aircraft  and  the  sensor.  The  height  of  the 
terrain  between  the  two  points  and  the  earth's  curvature  factor  applicable  to  the  electro 
magnetic  frequency  of  operation  of  the  air  defence  gear  will  determine  intervisibility. 
Vegetation  or  cultural  features  are  not  included  in  the  intervisibility  determination. 

Two  approaches  for  intervisibility  calculation  were  considered.  The  first  was  to 
produce  a  routine  that  would  operate  on  the  GAPS  II  data  file  for  the  profile  and  the 
digital  terrain  data  base.  For  each  pair  of  aircraft  and  sensor  positions  it  would  de¬ 
termine  the  intervisibility  status.  The  second  approach  was  to  process  all  the  terrain 
in  the  vicinity  of  a  defensive  site  one  time  only.  The  product  would  be  a  secondary 
data  file  that  recorded,  at  each  grid  position  in  this  region,  the  altitude  (ASL)  below 
which  the  aircraft  is  not  visible  from  the  defensive  position.  Call  this  altitude  the 
shadow  height  at  that  location. 

The  first  approach  is  a  "pay-as-you-go"  method.  No  initial  processing  is  required, 
but  a  cumbersome  sequence  of  calculations  (with  data  handling  problems)  is  required  for 
each  intervisibility  assessment.  This  approach  was  selected  for  the  model  described  in 
Ref.  (3).  The  second  approach  has  the  disadvantage  of  a  large  initial  expenditure  of 
computer  resources.  However  once  the  shadow  height  file  has  been  established,  then  any 
point  on  any  profile  that  passes  through  the  region  can  be  assessed  quickly  as  being 
visible  or  not  from  that  defensive  site.  All  that  is  required  is  a  simple  interrogation 
of  this  secondary  file. 

The  second  approach  was  selected,  as  it  appeared  that  it  would  be  the  most  efficient 
method  to  use  over  the  run  of  a  long  multi-scenario  analysis.  A  piece  of  FORTRAN  soft¬ 
ware  labelled  AVIS  (for  Aircraft  Visibility)  produces  the  shadow  height  file.  Inputs  to 
the  program  include:  the  latitude  and  longitude  of  the  defensive  site;  the  height  of 
the  sensor  above  ground;  the  radius  of  the  area  of  interest  about  the  site;  and  the 
effective  earth  radius  to  be  applied  in  the  curvature  corrections. 

Before  processing  of  the  digital  elevation  data  takes  place,  the  curvature  correc¬ 
tion  factor,  1000D2/2R,  is  subtracted  from  the  ASL  elevation  value  at  each  terrain  grid 
point  in  the  region  of  interest.  Parameter  D  represents  the  distance  from  the  defensive 
site  to  the  grid  position  and  R  is  the  effective  earth  radius  (both  in  km) .  The  AVIS  pro 
gram  then  operates  on  the  corrected  elevation  values  radially  outward  from  the  defensive 
site.  By  employing  a  shadow  casting  technique,  the  shadow  height  at  each  grid  point  can 
be  calculated.  The  technique  is  straight  forward  and  described  in  detail  in  Ref.  (4) . 

The  most  difficult  facets  of  the  AVIS  program  in  fact  are  the  data  handling  problems  and 
switching  from  processing  latitude  contours  to  processing  longitude  contours  and  back. 

Figure  3  illustrates  a  sample  cross-section  of  the  digital  terrain  (compressed  con¬ 
siderably  in  the  horizontal  direction) .  A  defensive  site  is  positioned  at  the  asterisk. 
The  bold  line  represents  the  shadow  height  values  as  calculated  by  AVIS.  Since  the  ter¬ 
rain  is  drawn  as  "flat  earth",  the  curvature  corrections  are  reflected  in  the  slight  up¬ 
wards  bowing  of  the  shadow  height  curve. 


FIGURE  3 

ILLUSTRATION  OF  INTERVISIBILITY  CALCULATIONS 
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3.  DETERMINATION  OF  EXPOSURE  HISTORY 


Given  a  flight  profile  produced  via  GAPS  II  and  a  file  of  shadow  heights  generated 
about  a  selected  defensive  site  by  AVIS,  the  next  step  is  to  merge  these  two  products 
into  to  what  shall  be  called  an  exposure  history.  The  exposure  history  is  a  record,  from 
the  point  of  view  of  the  defensive  site,  of  the  important  parameters  affecting  the  site's 
ability  to  engage  the  target  aircraft. 

A  FORTRAN  program  named  MERAGE  (acronym  for  "Merge  AVIS  and  GAPS  II")  was  developed 
to  produce  this  record.  The  flight  profile  is  sampled  at  a  regular  time  interval.  At 
each  point  the  following  quantities  are  recorded: 

1.  time  (from  profile  start) 

2.  range  to  aircraft 

3.  aircraft  bearing  from  defensive  site 

4.  aircraft  altitude  above  sea  level 

5.  aircraft  height  above  shadow  height  (negative  if  below) 

6.  velocity  vector  of  aircraft. 

From  this  exposure  history  file,  key  variables  affecting  engagability  can  be  calcu¬ 
lated.  Examples  are  the  radial  velocity  and  angular  velocity  of  the  aircraft  with  re¬ 
spect  to  the  defensive  site,  and  the  angle  of  the  aircraft  above  the  highest  point  of 
intervening  terrain.  The  workings  of  the  MERAGE  program  are  documented  in  Ref.  (5) . 

As  an  example  of  typical  exposure  histories,  consider  the  two  air-to-ground  profiles 
shown  in  Figure  4.  The  terrain  illustrated  is  a  small  section  of  central  Europe.  An 
airfield  was  identified  as  a  suitable  target.  The  bold  line  represents  a  profile  deliv¬ 
ering  BL-755  cluster  weapons.  The  aircraft  passes  directly  over  the  airfield  at  approx¬ 
imately  100  m  AGL.  The  profile  represented  by  the  fine  line  adopts  a  shallow  pop-up  man¬ 
oeuvre  to  accomodate  a  CRV-7  (2.75  inch)  rocket  launch  at  a  five  degree  dive  angle  and 
3000  metres  slant  range.  Ingress  and  egress  of  both  profiles  are  at  100  metres  AGL  on 
average.  These  profiles  were  planned  and  "flown"  by  a  CF-104  pilot  using  the  GAPS  II 
system.  Incidently  the  grey-scale  relief  background  of  Figure  4,  on  which  the  two  pro¬ 
files  are  illustrated,  was  also  produced  by  the  Tektronix  high-resolution  graphics  system. 
Dark  shades  represent  high  elevations. 
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Site  B 


FIGURE  5(a) 


EXPOSURE  OF  CRV-7  DFLIVERY  PROFILE 


FIGURE  5(b) 

EXPOSURE  OF  BL-755  DELIVERY  PROFILE 


Three  sites  for  air  defence,  arbitrarily  selected  within  this  reqion,  are  illustrat¬ 
ed  in  Figure  4.  AVIS  runs  at  these  locations  were  made  based  on  an  antenna  height  of  5 
metres  and  a  maximum  detection  range  of  18  kilometres.  The  MERAGE  program  merged  each 
combination  of  defensive  site  and  profile  to  produce  the  exposure  history  data  file. 


Figures  5(a)  and  5(b)  illustrate  the  visibility  of  the  CRV-7  and  BL-755  delivery  pro¬ 
files  (respectively)  from  each  of  the  three  defensive  sites.  When  the  aircraft  is  vis¬ 
ible  from  a  given  site,  a  straight  line  is  drawn  to  join  the  two  positions  in  the  figure. 
The  resulting  fan-shaped  regions  identify  the  visible  portions  of  each  profile. 

A  graphical  summary  of  the  exposure  history  of  each  profile  from  the  point  of  view 
of  defensive  site  B  is  shown  in  Figure  6.  Four  charts  displaying  key  parameter  values  as 
a  function  of  time  are  presented.  The  curves  drawn  on  the  right  side  represent  the  BL-755 
delivery  profile  and  the  curves  on  the  left  apply  to  the  CRV-7  profile. 

The  top  graph  in  Figure  6  shows  the  radial  velocity,  equivalent  to  radar  frequency 
doppler  shift,  that  site  B  will  see  as  a  function  of  time.  Near  zero  values  of  radial 
velocity  will  hamper  the  ability  of  doppler  radars  to  detect  or  track  the  aircraft. 

The  second  graph  shows  the  horizontal  angular  velocity  of  the  aircraft  in  relation 
to  the  sit*.  T»iiB  patajuttef  1*  the  ■lawir-c  *+,«  an  ante,*,*  hnt  h&vt 

to  deliver  in  order  to  be  able  to  track  the  aircraft.  If  the  demanded  rate  approaches  or 
exceeds  the  hardware  limit  then  tracking  ability  will  be  affected. 

The  third  graph  displays  range  to  target  as  a  function  of  time.  Range  affects  de¬ 
tectability  and  weapon  flight  time,  and  will  be  a  key  variable  for  any  air  defence  system. 

The  parameter  displayed  in  the  bottom  figure  is  labelled  "angle  above  terrain". 

This  is  the  vertical  angle  subtended  at  the  defensive  site  between  the  aircraft  position 
in  the  sky  an?  the  ££  InS  U#  I,SW  tm  pc*l'&ote  —  i*  w  jk 

phenomena  such  as  radar  clutter  and  multi-pathing.  Radar  detection  and  tracking  is  de¬ 
graded  at  small  angles  above  the  terrain.  Obviously,  if  this  angle  becomes  negative  then 
the  aircraft  is  masked  completely  by  the  terrain. 


The  models  developed  by  the  Directorate  of  Air  Operational  Research  to  date  bring 
the  vulnerability  assessment  to  this  exposure  history  stage.  The  next  step,  and  it  is 
a  large  one,  is  to  develop  an  effectiveness  model  to  quantify  the  vulnerability  of  in¬ 
dividual  exposures  in  a  reasonable  and  not-too-complex  way.  As  was  mentioned  in  the 
introduction,  the  methodology  need  only  be  sufficiently  complex  to  permit  a  reasonable 
comparative  vulnerability  assessment.  It  is  envisioned  that  "cookie  cutter"  limits  on 
the  key  parameters  (for  example,  the  four  parameters  depicted  in  Figure  6)  will  be  used 
■  5*  itify  fcm/agDitJle  ftwpowuvw,  Hfesptft  Tlf  rorrtines  wss  be  OBefl  to  model 

the  guidance  laws  of  the  system.  Figures-of-merit  such  as  "maximum  number  of  missile 
engagements"  will  be  the  bottom  line. 
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APPENDIX  A 


MATHEMATICAL  CONSTRUCTION  OF  THE  FLIGHT  PROFILE 

The  flight  profile  is  assembled  as  a  series  of  segments.  Given  the  terminal  velocity 
and  position  vectors  from  the  previous  segment,  four  inputs  -  linear  acceleration,  later¬ 
al  acceleration,  "bank*  angle  and  segment  duration  time  -  are  used  to  define  the  next 
segment  of  the  aircraft  path.  We  wish  to  solve  the  equations  of  motion  to  obtain  an 
expression  for  the  position  vector  (X ( t) ,  Y(t),  Z(t))  and  the  velocity  vector 
(Vx<t) ,Vy (y) ,VZ (t) )  at  all  times  t  during  the  segment  duration. 

The  solutions  are  more  easily  derived  in  two  stages.  The  first  stage  solves  the 
equations  of  motion  in  a  simplified  two  dimensional  situation,  using  only  the  accelera¬ 
tion  parameters  and  duration  time.  The  second  step  consists  of  rotating  and  translating 
this  constructed  segment  into  the  appropriate  position  in  three  dimensions  defined  by  the 
segment's  initial  conditions  and  the  bank  angle  parameter. 


The  problem  is  scribed  two  dimensionally  as  follows,  with  lower  case  x  and  y  re¬ 
presenting  the  2-D  situation.  The  vehicle  commences  at  the  origin  at  t=0  with  initial 
velocity  vn  directed  along  the  x-axis.  The  linear  acceleration  parameter,  a  (v  for  vel¬ 
ocity)  ,  is0  of  constant  magnitude  during  the  segment  and  is  always  in  the  direction  of 
the  velocity  vector.  The  lateral  acceleration,  a  (p  for  perpendicular) ,  is  of  constant 
magnitude  during  the  segment  also  and  is  always  p  directed  perpendicular  and  to  the  left 
of  the  velocity  vector.  The  angle  8  is  defined  as  the  deflection  of  the  velocity  vector 
from  the  original  x-axis  direction.  The  equations  describing  this  situation  are 


v(t)  =  vQ  +  avt 

=  Vv<t) 

Substituting  (Al)  into  (A2)  and  integrating  yields 
0(t)  =  (ap/av)  in  (1  +  avt/vQ) 

The  velocity  components  at  time  t  are  then 


Hence 


Vx(t) 

=  dx|t)  =  V(t) 

COS 

(6  (t) ) 

yt> 

=  <?§M  =  v(t) 

sin 

(0(t)) 

t 

f 

r 

X  ( t) 

=  J  <v0  +  v> 
0 

cos 

LV 

y  (t) 

=  f  (v0  +  3VS) 

sin 

[v 

avS/V. 


ds 


(Al) 

(A2) 

(A3) 

(A4) 

(A4) 

(A6) 

(A7) 


Substituting  a  change  of  variable 
Z 

and  using  the  known  integral 


=  (a  /a  )  in  (1  +a  s/v«) 
p  v  v  0 


egx  cos  x  dx  =  (eyA/(g2  +  1) ) (g  cos  x  +  sin  x) 


(A8) 


(A9) 


produces  the  solution 

x ( t)  =  (vQ+avt) 2 (2avcos(6 (t) ) +apsin(6 (t) )-2v0JavJ/(4avJ+apJ) 
y  (t)  =  (vQ+avt)  2  (2avsin(8  (t)  )-apcos(6  (t)  J+Vg^^ 


p]/(4V 


2+ap2 ) 


(A10) 

(All) 


The  second  operation  is  that  of  rotating  and  translating  this  two-dimensional  curve 
into  its  appropriate  position  in  three  dimensions.  This  manoeuvre  identifies  the  termin¬ 
al  position  and  velocity  vectors  from  the  previous  segment  as  the  initial  vectors  for  this 
segment  (denoted  C  and  V  respectively) ,  and  requires  the  input  of  one  other  parameter  to 
establish  the  curve's  position  now  that  there  is  one  more  degree-of-freedom  in  the  co¬ 
ordinate  system. 
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This  parameter  is  called  the  "bank"  angle.  It  specifies  the  plane  in  which  the  lat¬ 
eral  acceleration  takes  place  and  is  defined  in  more  detail  as  follows.  Consider  the 
aircraft  at  the  segment's  initial  position  and  velocity  conditions  with  the  wings  parallel 
to  the  ground.  Let  N  be  the  vector  pointing  directly  up  through  the  cockpit  of  the  air¬ 
craft  ngrmal  to  the  plane  defined  by  the  velocity  vector  and  a  line  joining  the  wing  tips. 
Vector  N  is  then  rotated  about  the  aircraft's  velocity  vector  to  the  "bank"  angle.  Posi¬ 
tive  rotation  is  clockwise  from  the  pilot's  point  of  view.  The  path  of  the  aircraft  dur¬ 
ing  the  segment  will  lie  in  the  plane  defined  by  $  and  iS.  As  mentioned  in  the  introduc¬ 
tion,  the  term  "Bank"  angle  very  nearly  represents  the  actual  angle  of  bank  of  the  wings 
of  an  aircraft  in  flight,  the  difference  being  that  the  actual  angle  of  bank  has  to 
account  for  gravity. 

Note  that  with  zero  lateral  acceleration,  V  will  not  change  in  direction.  Hence  no 
bank  angle  input  is  required.  Note  also  that  if  the  aircraft  were  flying  straight  up  or 
down,  the  reference  position  of  wings  being  parallel  to  the  ground  becomes  ambiguous  and 
the  bank  angle  is  undefined.  The  GAPS  II  program  prohibits  vertical  flight  as  the  initial 
conditions  of  any  segment,  however  the  aircraft  is  permitted  to  pass  through  such  a  con¬ 
dition  during  a  segment. 

The  second  phase  of  the  construction  then  is  to  imbed  the  (x,y)  plane  into  the  (XJ  2) 
space  and  apply  the  proper  rotational  and  translational  operations.  It  can  be  shown  with¬ 
out  too  much  difficulty  that  the  solution  for  the  coordinate  vector  at  time  r  +  t  is 


X(Ti+t)  X(Ti)  Vx/V  £-(VxVy/SV)cosY  +  (Vy/S)siny 

Y(Ti+t)  =  Y  <T±)  +  Vy/V  £-(VyVz/SV)cosy  -  (Vx/S)sinY 
[Z(T.+t)  Z(Ti)  ^Vz/Vj  £(S/V)cosy] 


where  the  velocity  vector  at  the  segment  start  time,  T^,  has  been  abbreviated  to 
(V„,VW,V.) .  Also  in  (A12)  V  represents  the  speed  at  time  T. ,  y  is  the  "bank"  angle  para- 
meter,  S  =  (VXJ+VY2) i/ 2 ,  and  x(t)  and  y(t)  are  as  defined  in  (A10)  and  (All)  respectively. 
Let  C  represent  the  aircraft  coordinate  vector  and  M  represent  the  transformation  matrix 
in  (A12) .  The  position  and  velocity  vectors  at  any  time  during  the  segment  are  then: 


C(T.  +  t)  =  C  (T.)  +  M 


V(Ti  +  t)  =  M 


where  v  (t)  and  v  (t)  are  as  defined  in  ( A4 )  and  (A5) 
x  y 
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APPENDIX  B 


TERRAIN  DISPLAY  ALGORITHMS 


This  appendix  addresses  the  techniques  and  algorithms  used  to  generate  the  type  of 
terrain  displays  illustrated  in  Figure  2  of  the  main  text  of  this  paper. 


The  following  equations  will  produce  a  perspective  projection  from  three  to  two  di¬ 
mensions,  (x,y,z)->-(x'  ,y' )  ,  and  can  be  directly  derived  from  basic  principles. 


=  P 


(Bl) 


x'  =  x*W/(-z*) 
y'  =  y*W/(-z*) 


(B2) 


where 


P  = 


V  /S2 

y 


-v  /s2 

X 


-VxVz/(S2S3) 


-V  V  /(S2S3) 
1  * 


0 

S2/S3 


-v  /s3 

X 


-Vs  3 


-Vs  3 


(B3) 


The  aircraft's  current  position  is  (C  ,C  ,C  )  and  the  aircraft's  current  velocity  vector 


is  <VVvz> 


Also 


S2  =  (V  2+V  2) 
x  y 


1/2 


=  (V  2+V  2+V  2)  / 
x  y  z 


The  parameter  W  represents  the  distance  to  the  projection  plane  from  the  aircraft. 


The  most  logical  approach  in  creating  the  terrain  scene  is  to  display  the  foreground 
information  first  and  work  progressively  out  to  the  horizon.  This  tactic  in  fact  is  nec¬ 
essary  in  order  to  be  able  to  implement  terrain  masking.  It  also  permits  the  user  to 
control  (interactively)  how  far  into  the  distance  the  terrain  is  to  be  drawn.  The  terrain 
data  must  be  displayable  from  near  to  far  looking  in  any  compass  directic  .  -  a  constraint 
that  imposes  two  major  conditions  on  its  accessibility.  First  it  must  be  accessable  both 
through  records  of  constant  latitude  and  records  of  constant  longitude.  Secondly  these 
records  must  be  accessable,  in  sequence,  in  both  forward  and  backward  direction. 


These  conditions  are  not  a  problem  if  the  entire  terrain  matrix  can  be  held  within 
the  machine's  memory.  The  limited  memory  of  the  Tektronix  4054  (64K  bytes) ,  however,  does 
not  permit  a  sufficiently  large  portion  of  terrain  to  be  retained  internally,  so  the 
terrain  data  is  accessed  via  random  access  files  on  the  flexible  disk  file  manager.  In 
order  to  have  the  data  accessible  in  both  north-south  and  east-west  directions  the  data 
must  be  stored  in  duplicate.  On  the  file  named  "LATITUDES",  the  elevations  within  an 
individual  data  record  run  from  west  to  east  at  a  constant  latitude,  with  successive  re¬ 
cords  running  northward.  The  same  data  is  held  in  the  file  "LONGITUDES"  but  it  is  order¬ 
ed  orthogonally.  Data  records  on  this  file  contain  elevations  running  from  south  to 
north  at  a  given  longitude  with  successive  records  progressing  eastwards.  The  stipulation 
that  the  data  be  accessable  in  all  four  compass  directions  is  met  by  making  the  individual 
records  directly  accessable. 


Before  proceeding  further,  a  name  should  be  attached  to  these  strings  of  elevations. 

A  latitude  contour  defines  such  an  array  where  the  data  points  represent  elevations  along 
a  constant  latitude.  A  longitude  contour  is  defined  analogously.  In  instances  where  the 
orientation  of  the  contour  is  irrelevant,  they  will  be  referred  to  as  lat/lonq  contours 
or  simply  contours.  The  line  adjoining  any  two  adjacent  elevations  in  a  contour  is  called 
a  contour  line  segment. 


Placing  aside  the  concept  of  terrain  masking  for  the  moment,  the  steps  involved  in 
drawing  the  terrain  scene  are  as  outlined  below. 


Step  1 s  Determine  which  data  file  to  use  and  which  direction  that  file  is  to  be  ac- 
cessed.  For  instance  if  the  aircraft  is  heading  westward  (225  to  315  degrees) ,  access 
records  in  the  LONGITUDES  file  in  decreasing  order. 


:  Identify  tho  beginning  contours.  In  general,  take  the  latitude  and  longi- 
aircraft  and  select  the  first  contour  encountered  in  the  viewing  direction. 


tude  of 

However  if  the  aircraft  is  in  a  climbing  attitude,  the  first  few  contours  may  in  fact  lie 
behind  the  aircraft.  In  this  nose-up  state  then,  the  latitude  and  longitude  where  the 
aircraft's  nadir  vector  intersects  the  sea-level  plane  is  the  position  where  the  selection 
of  contours  begins. 
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Step  3;  For  each  lat/long  contour  to  be  displayed,  determine  which  portion  of  the 
contour  will  lie  within  the  pre-specified  viewing  window.  Apply  formulae  (Bl)  and  (B2) 
to  determine  the  projected  position  of  each  elevation  point  within  the  visible  region 
of  the  contour.  Then  at  each  grid  position  an  "L"  shape  is  drawn.  One  edge  of  the  "L" 
joins  adjacent  points  in  the  current  contour  and  the  second  joins  the  current  grid  posi¬ 
tion  to  the  corresponding  position  in  the  previous  contour  The  result  is  a  "checkerboard” 
pattern  as  illustrated  in  Figure  2  in  the  main  text  of  the  paper. 

Terrain  masking  is  imposed  within  the  structure  outlined  above.  Each  time  a  draw  is 
to  be  executed,  the  visibility  of  the  contour  points  at  each  end  of  that  line  segment 
will  determine  whether  all,  none  or  part  of  the  segment  will  be  drawn.  Point  visibility 
is  a  function  of  the  height  of  the  terrain  lying  between  the  viewpoint  and  the  point  in 
question. 

Figure  Bl  illustrates  the  technique  used  to  determine  terrain  masking.  The  x  dimen¬ 
sion  of  the  viewing  window  is  overlaid  with  an  even  grid  (independent  of  the  terrain  grid) 
The  y  value  at  each  of  the  grid  points  represents  the  highest  (most  positive  value  of  y) 
projected  elevation,  at  that  x  position,  of  the  terrain  contours  already  processed.  The 
contours  are  processed  outwardly  from  the  viewpoint,  so  this  array,  which  shall  be  called 
the  "high-water-mark"  vector  E,  correctly  approximates  the  intervening  ground.  The 
quality  of  the  approximation  improves  with  the  fineness  of  the  x-dimension  grid  (the 
length  of  vector  E) .  Linear  interpolation  between  the  grid  points  produces  the  "high- 
water-mark"  (HWM)  contour  for  ascertaining  visibility. 

In  the  majority  of  cases,  contour  line  segements  either  will  be  completely  visible 
or  completely  masked.  In  these  cases  it  is  desirable  to  have  the  algorithm  carry  as 
little  "overhead"  as  possible.  All  that  is  required  is  an  array  interpolation  and  a  com¬ 
parison  to  determine  whether  the  projection  of  a  given  elevation  point  is  visible.  As 
long  as  both  end  points  of  the  contour  line  segments  are  of  the  same  visibility  (i.e. 
visible  or  masked)  than  a  straight  draw  or  move  (respectively)  is  executed. 

Special,  more  intricate  software  is  executed  only  for  the  relatively  infrequent  cases 
where  the  current  lat/long  contour  is  passing  behind  or  emerging  from  the  intervening 
terrain.  Under  these  circumstances  the  program  searches  for  the  intersection  point  of 
the  contour  line  segment  with  the  HWM  contour.  The  visible  fraction  of  the  contour  line 
segment  then  can  be  identified  and  drawn,  followed  by  a  move  to  the  correct  finishing 
position. 

The  terrain  masking  algorithm  is  constructed  so  as  to  search  out  at  most  one  inter¬ 
section  between  a  given  contour  line  segment  and  the  HWM  contour.  For  instance,  if  both 
ends  of  a  segment  are  visible,  then  the  whole  segment  is  deemed  visible  and  is  drawn  in 
its  entirety.  It  could  happen,  however,  that  a  portion  in  the  middle  of  a  segment  is: 
masked  but  both  ends  remain  visible.  The  likelihood  of  encountering  of  this  type  of 
anomaly  was  not  considered  large  enough  to  bother  burdening  the  algorithm  to  accomodate 
it,  and  the  realism  of  the  total  terrain  image  is  virtually  unaffected  by  this  assump¬ 
tion. 

i/’M  it'  S-,  ong  r  r'  =  V  e*  it"'  •  *.  •  1  I  nfe  ■  U  Mi- 

dated.  The  visibility  array  is  maintained.  As  the  next  contour  is  processed  it  provides 
an  historical  account  of  what  transpired  on  the  "previous"  contour. 


FIGURE  Bl 

TERRAIN  MASKING  ALGORITHM 
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DISCUSSION 


T.E.Spink,  US 

In  Figure  6  you  show  angle  above  the  terrain.  Is  that  the  angle  between  horizontal  and  the  aircraft  as  seen  by  the 
target? 

Author’s  Reply 

The  angle  above  terrain  is  defined  as  the  angle  between  the  aircraft  and  the  highest  point  on  the  terrain  between  the 
two  positions,  as  viewed  from  the  defensive  position.  Paragraph  7,  page  27-7,  describes  the  parameter  in  detail. 


F.W.Broecker,  Ge 

(1)  How  do  you  store  the  terrain  contour?  Or  do  you  use  a  sensor  to  know  the  contour? 

(2)  How  do  you  correlate  terrain  contour  and  height  position  of  the  aircraft? 

Author’s  Reply 

(1)  The  terrain  information  is  stored  on  flexible  discs  in  strings  of  either  constant  latitude  or  longitude.  No 
automatic  sensing  of  the  ground  below  the  aircraft  position  is  assumed. 

(2)  The  graphics  imagery  (Fig.  2  of  papers)  is  produced  as  a  feed  back  loop  for  the  profile  construction.  The 
constructor  also  has  a  digital  readout  of  aircraft  height  above  terrain.  Using  these  two  aids,  the  constructor 
can  assess  if  the  aircraft’s  current  position,  with  respect  to  the  terrain,  is  realistic.  This  is  analogous  to  how  a 
pilot  would  accomplish  the  task  under  VFR  conditions. 


G.Hunt,  UK 

What  constraints  have  you  applied  to  the  aircraft  dynamics  in  the  vertical  plane? 

Author’s  Reply 

The  aircraft  accelerations  in  the  vertical  plane  are  constrained  by  g-limits,  positive  or  negative,  specified  by  the  user. 


R.Westley,  Ca 

When  considering  ground  view  from  the  cockpit,  is  it  possible  to  include 

( 1 )  restrictions  imposed  by  downward  view  cut-off  by  cockpit  frame; 

(2)  restrictions  of  low  atmospheric  visibility? 

Author’s  Reply 

(1)  Yes,  with  little  difficulty. 

(2)  Complete  darkness  or  “white-out”  can  be  simulated  by  not  employing  the  graphics  imagery  at  all  during 
the  construction  process.  Partial  restrictions  could  not  be  simulated.  However,  such  realism  is  not  required 
to  meet  the  GAPS  11  objective,  which  is  to  be  able  to  efficiently  and  accurately  manouvre  a  simulated 
aircraft  in  a  realistic  manner  over  terrain. 
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COLOR  DISPLAY  TECHNOLOGY  IN  ADVANCED  FIGHTER  COCKPITS 


Kenneth  E.  Grosgebauer 
William  J.  Wildman 
James  A.  Davis 
General  Dynamics 
P.  0.  Bex  748,  MZ  2441 
Fort  Worth,  Texas  76101 


SUMMARY 

^Over  the  past  four  years,  the  use  of  color-display  technology  in  military  aircraft  has  received  a  sig¬ 
nificant  amount  of  attention;  to  date,  the  question  of  how  to  use  color  effectively  has  not  been  answered. 
With  high-quality  color  cathode  ray  tubes '(CRTs)/ now  being  manufactured  in  the  United  States,  Japan,  France, 
and  England,  additional  questions  concerning  the  display  performance  requirements  need  to  be  answered  prior 
to  their  introduction  into  the  fighter  cockpit.  Weapon  systems  of  today  and  those  planned  for  the  near 
term  demand  more  effort  from  the  pilot.  A  judicious  application  of  color  displays  is  considered  to  be  one 
of  the  prerequisites  to  overcome  this  additional  workload.  This  paper  discusses  the  selection  process  being 
applied  to  available  color  display  technology,  the  flight  simulator  evaluations  and  some  of  the  uses  of 
color  displays.  As  a  result  of  simulator  evaluations,  future  work  will  be  directed  toward  optimizing  color 
CRT  technology  and  the  use  of  color  displays  in  the  cockpit  of  advanced  fighter/attack  aircraft.  '■'T''7 


INTRODUCTION 


The  latest  technology  developments  in  color  cockpit  displays  contribute  to  meeting  the  performance 
requirements  of  today's  complex  tactical  missions.  The  development  of  high-brightness  color  CRTs  will 
allow  their  application  in  the  high-ambient-light  environment  of  the  bubble  canopy  cockpit  of  which  the 
F-16  is  a  prime  example. 

With  information  and  color  display  data  available  from  hardware  manufacturers  and  recent  investigations, 
an  evaluation  and  demonstration  program  was  established.  The  objective  was  to  apply  the  flexibility  of  color 
to  aid  in  reducing  the  workload  of  the  pilot  through  the  presentation  of  color-coded-pictorial  status  infor¬ 
mation  in  aircraft  systems.  One  example  of  this  is  a  pictorial  status  display  for  a  stores  management  sys¬ 
tem  (SMS).  Unlike  most  SMS  display  formats  of  aircraft  outlines,  which  use  overlaid  text  that  describes 
the  type  of  weapons,  this  pictorial  SMS  has  taken  full  advantage  of  graphic  representations  of  external 
stores  color  coding  to  present  weapons  mode  and  status  information.  This  method  offers  the  pilot  the  op¬ 
portunity  to  take  a  "quick  look"  at  his  stores  status  information  without  reading  a  large  amount  of  text. 

The  results  of  the  evaluation  and  demonstration  program  were  then  applied  to  the  effort  necessary  to 
prepare  a  Prime  Item  Development  Specification  for  color  display  equipment.  This  specification  will  con¬ 
tain  the  principle  guidelines  for  soliciting  hardware  procurement  of  actual  display  equipment.  Figure  1 
illustrates  a  color  enhanced  cockpit. 

KEY  PERFORMANCE  FACTORS  OF  COLOR  DISPLAYS 


Basically,  there  are  two  color  CRT  technologies  available  today:  the  beam  penetration  tubes  and  the 
shadow-mask  tubes.  The  beam  penetration  tube,  which  has  seen  limited  use  in  aircraft,  is  similar  in  con¬ 
struction  to  a  monochromatic  CRT  with  a  single  electron  gun.  It  offers  high  resolution,  has  high-output 
efficiency,  and  meets  vibration  requirements  of  military  aircraft  with  the  same  shock  mounting  as  mono¬ 
chromatic  CRTs.  The  tube  phosphor  is  arranged  in  three  layers  on  the  screen.  Layers  are  comprised  of  a 
red  phosphor  layer,  a  barrier  layer  that  is  intended  to  slow  the  electrons  passing  through  it,  and  a  green 
phosphor  layer.  Red  is  generated  by  setting  the  accelerating  voltage  relatively  low,  then  the  electrons 
are  fully  absorbed  in  the  red  phosphor.  When  the  accelerating  voltage  is  raised  to  a  much  higher  level, 
the  electrons  penetrate  both  the  red  phosphor  and  the  barrier  layer  and  are  absorbed  in  the  green  phosphor, 
which  provides  green  emission.  Yellow  and  orange  are  obtained  at  intermediate  voltages  or  are  produced  by 
time  sharing  between  red  and  green  emission. 

The  most  common  color  CRTs  are  the  shadow-mask  type  similar  to  those  currently  used  in  moat  domestic 
television  displays.  Two  means  are  available  by  which  phosphors  are  placed  on  the  CRT  screen.  These  are 
the  triad  dot  method  in  which  three  phosphors  (red,  green  and  blue)  are  deposited  in  a  dot  matrix  format  on 
the  screen  In  front  of  a  metal  mask  that  has  a  round  hole  for  each  triad  dot  set;  and  the  stripe  method  in 
which  stripes  (red,  green  and  blue)  are  deposited  on  the  CRT  screen  in  front  of  a  metal  mask  containing  a 
slit  opening  for  each  set  of  stripes.  Both  types  of  shadow-mask  tubes  use  a  three-electron  gun  system  to 
stimulate  the  peculiar  phosphor  type  (red,  green  or  blue).  The  shadow-mask  (metal  mask)  provides  the  means 
by  which  the  electron  guns  can  be  focused  on  one  or  any  combination  of  the  phosphor  types.  The  phosphor 
colors  (red,  green  and  blue),  when  plotted  on  the  CIE  1976  UCS  diagram,  produce  the  three  points  of  a  tri¬ 
angle  necessary  to  generate  any  color  available.  Although  the  shadow-mask  tube  has  a  low  output  efficiency 
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Figure  1  Color  Enhanced  Cockpit 

and  is  subject  to  vibration  problems,  it  has  a  distinct  advantage  over  the  beam  penetration  tube  because 
of  Its  multicolor  output  capacity. 

Two  techniques  are  available  for  presenting  Information  on  the  display  screen:  the  raster  scan  method 
and  the  stroke  method.  The  raster  technique,  the  most  commonly  used  method  today,  Is  used  In  television 
receivers,  video  monitors,  and  computer  terminals.  Raster  information  is  presented  on  the  display  by  scan¬ 
ning  the  display  face  from  left  to  right  (horizontal  lines)  with  an  electron  beam.  As  the  besm  travels 
across  the  screen  It  Is  modulated  or  pulsed  to  present  information  or  dats  on  that  particular  line.  When 
the  electron  beam  reaches  the  far-right  side  of  the  display  a  retrace  pulse  is  received  which  returns  the 
electron  beam  to  the  left  side  of  display  screen  and,  also,  Increments  the  electron  beam  downward  one  scan 
line.  This  continues  until  the  bottom  of  the  display  screen  Is  reached  at  which  time  a  vertical  retrace 
pulse  Is  received  that  returns  the  electron  beam  to  the  upper  left  corner  of  the  display  where  the  process 
starts  over  again.  Hus  method  of  presenting  information  on  the  display  allows  for  unprocessed  video  to 
be  displayed  (l.e.,  radar  or  camera  video).  Although  they  carry  no  information,  vertical  raster  lines  are 
generally  used  to  define  the  resolution  quality  of  the  display.  Airborne  displays  are  normally  525,  625, 
or  875  line  video  which  refers  to  the  vertical  resolution  or  vertical  raster  lines. 

Stroke  information  Is  presented  much  Ilka  a  draftsman  making  a  drawing.  The  electron  beam,  with  beam 
current  off,  Is  positioned  from  point  Xo,  To  to  Xi,  Yi,  and  no  line  la  drawn.  By  energizing  the  beam  cur¬ 
rent,  a  line  can  be  drawn  by  moving  the  electron  beam  from  point  Xi,  Yi  to  X2,  Y2*  By  varying  the  beam 
current  and  the  writing  speed,  the  brightness  of  the  display  can  be  controlled.  This  makea  the  generation 
of  displayed  Information  more  efficient.  The  disadvantage  of  the  stroke-type  display  Is  that  unprocessed 
video  cannot  be  presented  on  these  displays. 

Both  the  raster  and  stroke  display  techniques  have  desirable  qualities  for  airborne  applications. 

With  a  combination  of  the  two  techniques,  a  stroke/raster  or  hybrid  presentation  can  be  obtained  to  take 
advantage  of  the  two  displays.  Listed  below  are  the  advantages  and  disadvantages  that  can  be  experienced 
with  a  shadow-mask  tube  with  raster,  stroke,  and  hybrid  display  presentations. 
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RASTER 

o  Advantages 

oo  Unprocessed  video  displayed 

oo  Symbology  injected  on  a  priority  basis 

oo  Symbology  recorded  with  a  standard  TV  video  recorder 

oo  Symbology  highlighting  techniques  available  (i.e.,  inverse  video  occlusion  zones)  for  symbology 
oo  Flyback  raster  scanning  consumes  less  power 
oo  Injected  symbology  requires  no  additional  deflection  power 
oo  Standard  IC  chips  available  for  character  injection 

o  Disadvantages 

oo  Symbology  distorts  or  takes  on  a  stepped  appearance  when  rotated 
oo  Symbol  brightness  limited  to  maximum  TV  brightness 

oo  Moire  effects  (fishtailing  of  horizontal  lines)  of  raster  and  shadow-mask  must  be  considered 

STROKE 

o  Advantages 

oo  Symbols  are  sharp,  distinct  and  bright 
oo  Symbology  easily  Interpreted  even  when  rotated 
oo  Brightness  range  is  wider 

oo  Programming  comprehensive,  high-resolution  displays  provide  simpler  hardware  than  complex 
raster  displays 

oo  LSI  chips  available  for  stroke  symbol  generator 
o  Disadvantages 

oo  Deflection  power  for  random  nature  of  stroke  writing  technique  is  larger 
oo  Unprocessed  video  cannot  be  displayed 

oo  Recording  on  standard  TV  video  recorder  cannot  be  obtained 

HYBRID 

o  Advantages 

oo  Unprocessed  video  displayed 
oo  Stroke  symbols  are  sharp,  distinct  and  bright 
oo  Static  fixed  raster  symbols  can  be  highlighted 
oo  LSI  chips  available  for  stroke  symbol  generator 

oo  Recording  capability  for  major  portion  of  display  picture  is  provided 
o  Disadvantages 

oo  Deflection  power  for  random  nature  of  stroke  writing  technique  is  larger 
oo  Vertical  retrace  time  limits  amount  of  stroke  symbology 

Given  these  considerations,  hybrid  color  displays  appear  to  be  the  best-suited  to  the  next  generation 
of  fighter  airplane  cockpits.  This  is  not  to  say  that  other  types  of  color  displays  could  not  be  used  in 
cockpits  under  restricted  conditions.  There  is  some  question  if  color  raster  symbology  is  acceptable  under 
high-ambient-lighting  conditions.  Although  stroke  displays  offer  the  advantage  of  being  viewable  under 
high-ambient-lighting  conditions,  they  lack  the  ability  to  display  raster  video. 

GENERAL  APPROACH  TO  NEW  TECHNOLOGY  ASSESSMENT 


A  five-phase  program  was  defined  to  demonstrate  color  display  technology  in  a  cost-effective  manner. 
These  steps  were  Industry  surveys,  laboratory  testing,  pre-simulation  evaluation,  simulation  and  flight 
demonstration.  With  this  incrementally-phased  "building  block"  approach,  the  funding  profile  for  the 
program  was  controlled  in  a  way  that  permitted  the  exploration  of  numerous  technologies  at  the  same  time 
within  limited  budget  constraints.  The  key  to  making  this  possible  was  to  hold  down  the  front-end  cost 
of  the  development  cycle  and  to  specify  the  equipment  around  the  requirements  established  through  pilot 
feedback. 

In  the  design  and  integration  of  a  color  display  system  into  military  aircraft,  the  display  engineers 
and  human  factors  engineers  have  separate  but  overlapping  responsibilities  with  a  conmon  goal  -  the  develop¬ 
ment  and  utilization  of  flyable  hardware.  It  was  the  responsibility  of  the  human  factors  engineers  to  de¬ 
velop  the  utilization  concepts  for  the  system  and  to  define  the  general  display-related  requirements  based 
on  the  operational  environment  of  the  system.  The  responsibility  of  the  display  engineer  was  to  keep  the 
human  factors  engineers  informed  of  equipment  and  technology  limitations,  and  to  provide  hardware  designs 
that  meet  the  overall  requirements.  With  engineering  responsibilities  defined,  efforts  were  then  directed 
to  the  ultimate  goal  of  flight  demonstration  of  a  color  display  system. 

The  first  phase  of  the  color  display  program  was  an  industry  survey  to  determine  what  equipment  anJ 
what  performance  data  were  available  from  vendors.  The  data  obtained  were  used  to  determine  what  equip¬ 
ment  would  be  required  and  best  suited  for  laboratory  testing  and  pre-simulation  validation.  Although  the 
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performance  of  the  color  display  was  important  for  these  two  phases,  it  was  not  the  driving  factor.  Of 
more  importance  was  the  symbol  generator,  to  be  interfaced  with  the  color  display,  which  would  have  to  be 
programmed  without  expensive  interface  equipment. 

The  purpose  of  the  laboratory  testing  is  to  obtain  the  information  necessary  for  generating  specifi¬ 
cations.  The  specifications  for  color  displays  need  to  be  responsive  to  the  operational  requirements. 

Before  specifications  can  be  defined  for  airborne  color  displays,  the  effects  of  extreme  lighting  con- 

ultiu.ib  wn  C-l.t  display  p.rK  luiaT.ti  ai.a  ap-Cii ic  t-ioT  SalaCtivAi  lighting  C^tiuiti-.S  uiu'.t 

examined.  To  accomplish  this,  the  color  display  is  coupled  to  an  integrating  light  sphere  with  a  variable 
lighting  source.  This  allows  for  variable,  uniform  illumination  within  the  sphere  and  on  the  display  face 
on  output-  mu—  TMMcrti  Mill  tx  tun*.  «ntt  e  s (Mntnuir.  tti  oflittViv  ftti  ajrAjcv.j&nUir^,  momiAuf 

with  human  performance  guidelines  associated  with  color  displays,  is  used  as  a  guide  to  select  a  set  of 
colors  that  is  acceptable  under  all  ambient  lighting  conditions.  This  Includes  selecting  minimum  brightness 
levels  for  night  viewing,  which  is  sometimes  overlooked  because  of  the  effort  that  is  expended  to  "beat 
the  sun"  at  high-ambient  conditions. 

The  pre-simulation  evaluation  uses  a  test-bed  approach  to  evaluate  display  formats.  This  approach 
allows  new  cockpit  display  concepts  to  be  quickly  examined  at  low  cost  as  compared  to  the  time  and  money  re¬ 
quired  to  support  a  total  cockpit  simulation  effort.  The  technique  ranges  from  the  use  of  single  display 
setting  on  laboratory  work  benches  for  a  quick  "first-look"  at  the  display  concepts,  to  simple  integrated 
cockpit  mockups  outfitted  only  with  active  devices  necessary  for  the  evaluation.  In  this  manner,  test-bed 
evaluation  provides  proof-of-concept  testing  of  the  color  display  formats  prior  to  commitment  to  full  sim¬ 
ulation. 

The  basic  tool  in  demonstrating  color  display  concepts  has  been  the  F-16  Advance  Cockpit  Simulator. 

To  obtain  exposure  for  the  color  display  concepts,  a  three-phase  program  was  developed  with  the  F-16  Advanced 
Cockpit  as  the  test-bed.  The  three  phases  are  described  as  follows: 

Phase  I  -  This  was  a  low-cost  demonstration  in  which  video  tapes  were  used  to  illustrate  a  map  display, 
and  static  flight  and  engine  instruments  (provided  by  a  symbol  generator)  were  presented  on  a  five-by-five- 
inch  color  display  (stroke/raster).  In  order  to  make  the  simulation  somewhat  realistic,  the  color  moving- 
map  video  tapes  were  manually  synchronized  with  dynamic  head-up  display  video.  Static  flight  path  informa¬ 
tion  was  then  displayed  over  the  color-moving-map  video  to  demonstrate  the  flexibility  of  the  color  display 
system. 

Phase  II  -  Phase  II  provided  for  a  full-up  color-moving-map  reader  and  a  color  display  system  that  in¬ 
cluded  a  dynamic  symbol  generator  and  a  five-by-five-inch  color  display  (stroke/raster).  This  configuration 
was  interfaced  with  the  simulator  computer  for  a  full-up  simulation  effort.  The  Phase  XI  configuration 
allowed  for  the  presentation  of  dynamic  flight  Information  overlayed  on  the  map,  dynamic  threat  information 
presented  on  the  color  display,  and  the  option  of  displaying  color  or  monochromatic  map  video. 

Phase  III  -  The  hardware  configuration  of  Phase  III  was  the  same  as  that  of  Phase  II  with  the  addition 
of  extensive  software.  The  additional  software  provided  the  dynamic  electronic  flight  instruments  and  a 
dynamic  pictorial  Stores  Management  System  (SMS).  This  configuration  demonstrated  the  full  flexibility  of 
color  in  the  fighter  aircraft  cockpit. 

The  final  step  in  this  program  is  the  flight  demonstration  of  hardware  and  the  display  concepts. 

Efforts  are  now  underway  to  obtain  flyable  hardware  for  this  demonstration.  The  hardware  configuration 
and  concepts  for  the  flight  demonstration  will  have  evolved  out  of  the  laboratory  testing,  pre-simulation 
validation,  and  simulation  efforts  at  General  Dynamics. 

SPECIFICATION  DEFINITION 


Specification  definition  for  color  displays  takes  on  a  totally  different  character  than  that  previously 
considered  for  monochromatic  displays.  This  is  primarily  due  to  the  human  performance  characteristics 
asso-.lated  with  color  perception.  Therefore,  new  design  areas,  e.g.,  color  sensitivity  due  to  ambient  llRht, 
must  be  addressed. 

Typical  monochromatic  display  specification  requirements,  such  as  contrast  ratio,  maximum  brightness 
and  resolution,  have  now  been  replaced  with  discrimination  index,  chromaticity/color  difference,  color 
luminance,  and  beam  size.  One  has  to  be  very  cautious  when  determining  the  soeclfication  values  for  the 
new  requirements  and  must  not  force  the  previously  achieved  monochromatic  values  into  the  color  specifica¬ 
tion;  each  requirement  needs  to  be  sddressed  on  its  own  merits.  Other  standard  requirements  for  displays, 
such  as,  linearity,  focus,  sizing  stability,  CRT  life,  Jitter,  and  distortion,  are  applicable  to  both  color 
and  monochromatic  displays,  and  are  therefore  easily  transferred  to  a  color  specification. 

Four  factors  have  to  be  considered  in  determining  the  specification  requirements:  (1)  human  factors 
requirements,  (2)  hardware  displays  definition,  (3)  pllot/vehlcle  Interface  and  information  presentation 
requirements,  and  (4)  cost  of  hardware.  Figure  2  Illustrates  specification  information  flow.  Ulth  these 
factors  in  sdnd  and  with  the  aid  of  theoretical  evaluations  and  information,  the  basic  specifications  were 
assembled.  The  use  of  additional  information  obtained  by  the  demonstrations  conducted  during  this  study 
with  available  color  display  hardware  resulted  In  refinements  to  the  specification  requirements.  The  de¬ 
velopment  of  a  final  color  specification  has  yet  to  occur.  The  process  will  be  an  Iterative  one  based 
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largely  on  lessons  learned  in  early  engineering  and  display  development  activities,  such  as  the  one  de¬ 
scribed  in  this  paper. 


Figure  2  Information  Flow  for  Specification 


COLOR  DISPLAY  CONCEPTS  -  PICTORIAL  STORES  MANAGEMENT 


The  increased  severity  of  the  threat  environment  that  modem  weapon  systems  must  survive  has  driven 
sir-to-ground  fighters  to  very  low  altitude,  which,  combined  with  modem  weapon  technology,  has  Increased 
the  information  required  in  the  cockpit.  The  increased  information  coupled  with  the  trend  toward  smaller 
instrument  panels  has  resulted  in  time-shsred,  multifunction  displays.  The  necessity  to  time-share  dis¬ 
plays  places  s  premium  on  the  efficient  pres  ntation  of  information  in  terms  of,  not  only  what  is  displayed 
and  when  it's  displayed,  but  how  the  specific  information  is  formatted. 

Pictorial  displays  can  potentially  ease  the  workload  of  the  pilot  by  providing  necessary  information 
in  a  form  that  can  be  easily  and  quickly  assimilated.  Cockpit  demands  for  time-sharing  necessitate  that 
displays  be  formatted  as  effectively  as  possible.  The  pilot  should  be  able  to  acquire  the  desired  infor¬ 
mation  with  a  quick  glance.  Pictorial  formats  permit  more  efficient  transfer  and  assimilation  of  large 
quantities  of  data  quickly.  Also,  utilization  of  effective  pictorial  graphics  can  reduce  the  display  of 
alphanumerics  -  a  time-consuming  method  of  transmitting  information.  The  color  dimension  provides  a  natural 
coding  of  levels  of  urgency,  as  well  as  definition  of  homogeneous  data  sets  on  the  display.  By  providing 
more  cues  for  discriminating  information,  color  can  increase  the  flexibility  of  a  display,  thus  allowing 
the  display  of  more  highly  integrated  information  formats.  The  added  color  dimension  may  also  reduce  in¬ 
formation  acquisition  time  by  reducing  search  time  on  a  display.  The  added  clarity  and  flexibility  pro¬ 
vided  by  the  color  dimension  contributes  to  efficient  acquisition  of  displayed  information. 

The  pictorial  representation  of  stores  status  Information,  using  a  color  engineering  graphics  approach 
to  stores  symbology,  proved  to  be  universally  favored  in  our  initial  evaluation  when  contrasted  to  existing 
alphanumeric  displays  of  status  information.  The  color-graphics  approach  to  stores  symbology  provided 
easily  discernible  stores  symbology  with  the  exception  of  weapon  model  information,  such  as  AGM-65B  versus 
AGM-65D  which  has  a  similar  or  identical  shape.  A  single  model-designation  letter  has  been  proposed  to 
handle  this. 

The  pictorial  stores  display  allows  a  distinction  to  be  made  between  status  information  and  system 
control  information  which  typically  shows  up  as  alphanumeric  labels  adjacent  to  the  besel-mounted  multi¬ 
function  display  swltchea.  This  separation  of  statua  and  control  information  allows  the  pilot  to  effec¬ 
tively  declutter  his  display  of  information  currently  not  in  uae.  The  declutter  (DCLT)  switch  is  mech¬ 
anized  to  eliminate  all  system  control  labels  and  leave  only  pictorial  status  information.  The  ability 
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to  declutter  displays  is  a  significant  benefit  of  the  pictorial  Stores  Management  Set  display  format. 

The  operational  sequencing  of  the  stores  status  display  relies  on  the  color-coding  of  existing  symbols 
to  transmit  information  on  the  mode  of  operation  (F-16  Master  Modes)  and  weapon  sequencing.  For  example, 
when  the  pilot  checks  the  stores  management  system  before  engine  start  to  determine  that  the  proper  number, 
type,  and  arrangement  ot  weapons  is  leaded  in  the  stores  management  system,  the  status  display  is  green. 

The  color  green  was  selected  beer  use  it  is  the  most  frequently  observed  color  in  the  electronic  cockpit 
(P-43  green  phosphor  is  a  common  display  phosphor  for  monochromatic  displays).  The  remaining  colors  are 
used  for  high-information  content  displays.  As  the  display  is  sequenced  by  the  master  operation  mode  (air- 
%t-gtaap6y  (lttnti,  tV.  0  mallow  is  «srd  to  transmit  to  the  •  ilot 

the  stores/weapons  available  for  use  in  the  current  operating  mode.  This  display  presents  the  pilot  with 
information  as  to  which  subset  of  his  hands-on  control  functions  are  available,  i.e.,  will  a  missile  or  a 
bomb  go  when  the  "bomb  release"  button  is  depressed. 

Figure  3  provides  an  illustration  of  the  weapon  station  selection,  weapon  arming,  release,  and  hung 
weapon  indications  in  the  air-to-ground  mode.  The  color  red  in  combination  with  specific  graphic  config¬ 
urations  is  used  in  these  cases.  An  example  of  a  tactical  sequence  will  aid  in  clarifying  the  display  indi- 
'*  l\iw  At— r  it  .a.*  «  Witt  Uu  ft  cck  hase  of  o.erations  the  ilot  selects  tne  numbers  and  type 
of  weapon  to  be  delivered,  the  stores  system  selects  the  proper  set  of  weapons  stations  and  electrically 
actuates  the  weapons  station;  the  weapons  stations  are  now  armed  and  any  fire  pulse  transmitted  by  the  sys¬ 
tem  will  result  in  a  weapon  release.  As  the  attack  is  pressed,  the  selected  weapons  are  armed;  this  is 
depicted  by  coloring  in  solid  the  mid-50%  of  the  weapon  symbol.  In  addition,  nose/ tail  fuzing  information 
takes  the  same  form,  i.e.,  nose-fuzed  weapons  are  depicted  by  a  solid  color  in  the  forward  25%.  The  depic¬ 
tion  of  a  released  weapon  is  its  disappearance  from  the  display;  the  representation  of  a  hung  weapon  is  a 
cyclic  flashing  of  the  red  weapon  symbol  at  the  appropriate  weapon  station. 

Figure  4  illustrates  the  air-to-air  configuration  for  the  stores  display.  The  symbolically  represented 
information  and  the  color  coding  is  similar  to  the  air-to-ground  display  with  two  exceptions.  The  first 
exception  depicted  is  the  use  of  blue  in  the  head  of  an  IR  missile  to  indicate  that  the  head  is  being  cooled. 
The  second  applies  to  all  ofT-bo.eslght  weapon.'  .  Ttie  io>  cufluaUng  incmt  Ttat  , c  V  at 

an  indication  of  where  the  seeker-head  has  locked  on  a  target.  This  could  potentially  minimize  the  expend¬ 
iture  of  weapons  on  the  same  target  in  a  multi-target  engagement. 
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Figure  3  Air-To-Cround  UeaponB  Configuration 
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Figure  4  Air-To-Air  Weapons  Configuration 


CONCLUSIONS  AND  OVERVIEW 


The  general  approach  used  to  develop  and  evaluate  the  application  of  color  in  the  near-term  advanced 
fighter  cockpit  have  been  described.  In  addition,  a  technical  baseline  has  been  established  for  directing 
future  work  that  will  lead  to  the  utilization  of  color  displays  in  next-generation  aircraft.  With  expanded 
techni  al  assessments  of  the  use  of  color  in  the  specific  operational  environments,  it  will  be  possible,  to 
develop  the  correct  balance  between  actual  performance  requirements  and  costly,  unwarranted  requirements. 

Too  often,  the  performance  requirements  for  a  new  technology  are  over-specified  when  there  is  any  un¬ 
certainty  with  respect  to  the  real  requirement.  The  emphasis  should  be  on  the  user's  actual  requirements 
and  the  systems  designed  to  meet  those  requirements.  The  ultimate  goal  should  be  to  provide  the  pilot  with 
a  more  effective,  economical  way  to  accomplish  the  mission.  We  must  be  able  to  afford  color  to  meet  antic¬ 
ipated  complex  weapons  and  mission  requirements  of  tomorrow's  fighter/attack  aircraft.  It  will  require  a 
cooperative  effort  between  the  user,  the  aircraft  systems  integrator,  and  the  display  manufacturer  to  de¬ 
velop  and  Integrate  the  right  system. 
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DISCUSSION 

C.Mauieau,  Fr 

Prec6demment  les  instrument'  6,ectro»T'6c,n'q,,,“s  et^ent  dispel'  «ur  w  p)anrh<*«  de  hord  Dans  les  solutions  plus 
recentes  utilisant  des  tubes  cathodiques  monochromes,  les  informations  sont  regroupees  sur  des  6crans  occupant  une 
surface  egalement  importante.  De  meme  que  les  instruments  anciens  restaient  la  souvent  sans  etre  vraiment  regardes, 
les  ecrans  multiples  sont  souvent  inutiles  et  risquent  meme  de  distraire  Fatten tion  du  pilote  de  directions  exterieures 
oil  elle  serait  plus  utile  -  il  restera  done  la  probablement  tres  souvent  eteints.  L’experience  du  Mirage  2000,  par 
opposition  a  celle  d’avions  portant  —  comme  le  F- 1 8  -  plusieurs  ecrans  juxtaposes,  montre  que  l’introduction  de  la 
couieur  owe  un  moyen  ue  diminuer  la  aistriourion  spauaie  de  l  inlormaiion  en  poussam.  en  queique  sorte  plus  loin 
l’integration  de  sa  presentation.  Envisagez-vous  en  correlation  avec  1’introduction  de  la  couieur  une  diminution  du 
r.ombre  des  visualisations  tete  basse? 

Author’s  Reply 

The  displays  are  always  presenting  a  picture  except  when  a  video  missile  is  disconnected.  The  mission  requires  that 
all  the  available  data  be  presented  such  that  the  pilot  can  quickly  observe  his  situation  without  having  to  select  each 
prime  mode  (i.e.  radar,  stores  management). 

R.A.C.Smith,  UK 

The  paper  refers  to  conducting  laboratory  tests  on  colour  displays  in  high  ambient  lighting  conditions.  My  question 
was  as  follows:-  was  the  high  ambient  lighting  used  representative  of  sunlight  in  the  spectral  sense,  since  the 
perception  of  colour  must  surely  be  affected  by  the  “type”  of  ambient  illumination? 

Author’s  Reply 

Yes.  We  use  the  Hoffman  integrating  sphere  that  contains  high  intensity  halogen  lamps  that  give  off  energy  that 
simulate  the  spectral  characteristics  of  the  sun. 

K.F.Boecking,  Ge 

(1)  You  did  not  mention  the  beam-index-system  when  presenting  different  colour-dispiay-sy stems.  What  is  the 
reason? 

(2)  When  combining  stroke  and  raster  information  in  the  project  map  display  with  symbology  surrounding  do  you 
need  4  guns? 

Author’s  Reply 

(1 )  The  trend  in  the  colour  tube  industry  is  to  develop  the  shadow  mask  to  the  full  MIL  STD  and  no  prime  display 
supplier  appears  to  be  too  interested  in  the  beam  index  type  because  it  is  not  cost  effective. 

(2)  An  additional  gun  is  not  needed  and  the  existing  three  guns  are  used  to  write  the  stroke  information  during 
vertical  retrace  time. 


R.Davies,  Ca 

The  modem  business  jet  pilot  takes  colour  display  of  weather  radar  for  granted  and  many  have  colour  engine 
instrument  displays.  Some  business  jets  already  have  EFls  with  colour  radar  display  on  the  HSls.  Now  the  question: 
The  putting  of  colour  CRTs  into  a  fighter  ground  attack  aircraft  which  is  committed  to  flying  into  combat  zones, 
with  the  distinct  possibility  of  receiving  “foreign  objects”  in  the  cockpit  from  shellfire,  shrapnel  etc.,  seems  to  be 
very  vulnerable  to  potential  total  display  loss.  What  is  General  Dynamics’  and  the  Air  Force  attitude  to  this? 

Author's  Reply 

The  basic  trend  for  all  combat  fighter  aircraft  is  to  put  more  CRT  displays  (mono  or  colour)  into  the  cockpit 
because  of  the  multimode  missions  that  have  to  be  performed.  With  this,  a  swap  or  dual  mode  is  available  to  allow 
these  displays  to  serve  as  back-up  for  each  other.  These  CRT  displays  are  ruggedized  to  withstand  the  usual  environ¬ 
ment,  but  as  you  say  cannot  tolerate  shellfire  -  neither  can  flight  instruments.  It  is  quite  possible  that  the  near  term 
two-seat  aircraft  could  have  as  many  as  seven  CRTs  onboard,  with  a  suggested  location  of  3  at  the  front  and  4  at  the 
aft  seat.  This  will  be  probably  a  balance  of  2  mono,  1  colour  in  the  front  seat  and  2  mono,  2  colour  in  the  back  seat. 
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CRITICAL  FACTORS  AND  OPERATIONAL  RESEARCH  IN 


TACTICAL  FIGHTER  AVIONIC  SYSTEM  DEVELOPMENT 


by 

L.  BERARDI 

AERITALIA  -  Gruppo  Sistemi  Avionici  ed  Equipaggiamenti 
10072  CASELLE  (Torino)  -  Italy 


SUMMARY 


The  problem  to  deaign  and  to  develop  a  complex  system  is  considered  as  a  multiobjective  optimization  pro¬ 
blem.  In  particular,  the  ca3e  of  the  avionic  system  of  a  tactical  fighter  is  illustrated;  assumptions  and 
objectives  of  the  project  are  listed  and  discussed.  It  is  described,  an  approach  to  the  problem  that  uses 
Operations  Research  tool' and  techniques,  Multiobjectives  and  Marginal  Substitution  Rate  functions. 

A  brief  explanation  of  the  method  applied  to  the  case  of  the  design  and  development  of  a  tactical  fighter 
avionic  aystem  is^done.  It  is  pointed  out  that  the  approach  allows  to  take  into  account  not  only  the  ex¬ 
pected  characteristics,  but  also  the  impact  of  implanned  events  on  the  system  development. 

Possible  critical  factors  in  the  development  process  are  emphasized  by  means  of  the  computation  of  the  Mar 
ginal  Substitution  Rates.  A  detailed  example  is  given  in  respect  to  the  Operational  Mission  Software  deve 
lopment  for  the  avionic  system,  with  attention  to  critical  factors  individuation. 

1.  lNTRODUC^j£| 

Design  and  development  of  an  airborne  weapon  system  is  supported  by  a  multiobjective  decision  process.  At 
every  stage  of  the  design  and  during  development  there  are  people  who  have  in  charge  to  select  an  approach 
or  another,  to  choose  an  equipment  or  another,  to  take  proper  action  against  implanned  events  and  so  on. 
The  decisions  made  by  those  people,  or  the  rttccomendation  they  give  to  a  "decision  maker",  has  an  impact 
on  the  overall  characteristics  of  the  weapon  system  (objectives  to  be  reached),  like  cost,  effectiveness, 
maintainability,  and  therefore  the  "best"  alternative  must  be  selected.  Because  of  the  complexity  of  the 
problem  and  number  of  factors  having  influence  on  the  final  result,  the  "best"  decision  is  to  select  the 
"best"  compromise  among  contrasting  alternatives. 

The  Operations  Research  can  assist  the  "decision  maker"  in  his  task  by  providing  him  quantitative  indica¬ 
tions  about  the  characteristics  of  the  system,  trade-off  indications  and  trends,  resulting  by  selecting 
different  alternatives. 

The  Operational  Research  tools  and  techniques  are  of  general  use  for  system  of  every  level  of  complexity 
and  project  phase,  e.g.  full  weapon  aystem,  aircraft,  weapons;  airframe,  general  and  avionics  systems;  fea 
sibility  study,  definition,  development,  service;  new  system,  updating. 

Different  are  the  type  of  indicators  that  can  be  derived,  the  work  to  be  made  to  compute  them  (computer  si 
mulation,  flight  test,  ground  test),  and  the  "confidence  level"  related  to  the  indicators  and  therefore 
the  range  of  decisions  they  can  support. 

For  example,  during  feasibility  study  of  a  weapon  system,  only  preliminary  information  about  new  weapons 
may  be  available  and  very  rough  computer  models,  to  determine  its  performance,  can  be  made,  but  the  deci¬ 
sion  is  simple:  feasible  or  not.  Later  on  during  deaign  and  development,  better  information  results  in  a 
larger  set  of  indicators  used  to  define  detailed  characteristics  of  the  system. 

The  type  of  aystem  under  evaluation  may  vary  the  used  indicators  and  the  way  in  which  they  are  computed 
from  the  available  informations  (e.g.  strategic  weapon  system  and  tactical  weapon  system  are  evaluated  by 
means  of  different  parameters,  a  full  weapon  system  and  an  internal  data  transmission  system  may  assign 
different  weight  to  the  same  performance  indicator). 

The  use  of  the  Operations  Research  cari  be  planned  to  extend  in  two  directions  during  the  life-cycle  of  the 
project:  a  top-down  approach  and  a  stepwise , refinement. 

Top-down  approach  means  that  the  indicators  are  utilized  in  decisions  involving  simpler  and  simpler  aystem 
components  and  parts,  (from  system,  to  sub-system,  parts  and  components),  when  necessary  information  beco¬ 
me  available;  stepwise  refinement  means  that  the  same  indicators,  during  project  evolution,  are  effected 
by  lower  and  lower  uncertainty. 

In  particular  this  paper  describee  the  Operations  Research  approach  for  design  and  development  of  the  avio 
nic  system  for  a  new  tactical  fighter  weapon  system. An  example  of  the  aame  approach  applied  to  an  avionic 
system  component  (Operational  Software)  is  also  given. 
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2.  ASSUMPTIONS  AND  OBJECTIVES 

The  assumptions  and  the  objectives  of  the  project  must  be  established. 

2.1.  The  assumptions  for  the  design  and  development  of  the  avionic  system  for  a  new  tactical  fighter 
are  related  mainly  to  the  aircraft  characteristics  and  its  role.  As  result  of  an  higher  level  decision 
a  certain  amount  of  resources,  depending  on  the  aircraft  physical  characteristics,  are  allocated  to  the 
avionic  system,  that  is  : 

-  maximum  installed  weight 

-  total  available  internal  space  (and  its  partioning) 

-  electrical  power  available  and  characteristics 

-  internal  environmental  characteristics  (e.g.  temperature,  vibration,  EMP) 

-  air  mass  flow  and  pressure  drop  available  for  the  cooling  of  electronic  equipment 

-  physical  interface  with  other  aircraft  systems 

The  above  assumptions  probably  do  not  significantly  change,  or  do  not  change  at  all,  during  the  life  cycle 
of  the  system. 

The  aircraft  role  has  an  inpact  on  the  overall  design  and  therefore  on  the  avionic  system,  that  is  assumed 
to  be  affected  mainly  by: 

-  operational  requirements  related  to  the  avionic  system 

-  first  line  or  demonstrator  system 

-  time  constraints 

-  single  seat  design 

-  handling  qualities  of  the  aircraft 

-  weapon  inventory  to  be  delivered 

-  figures  of  merit  allocated  to  the  avionic  system  (MTBF ,  MTTR,  safety  rate  etc.) 

Some  of  the  above  assumptions  may  vary  significantly  during  the  life  cycle  of  the  aircraft,  particularly 
the  weapon  inventory. 

Finally  an  important  assumption  regards  the  industrial  resources  available  for  the  project,  in  terms  of 
funds,  manpower,  facilities. 

2.2.  Minimal  objectives  of  the  design  and  development,  not  in  order  of  priority,  are  : 

-  fulfilment  of  the  assigned  physical  constraints 

-  fulfilment  of  the  Operational  Requirement 

-  achievement  of  the  required  figures  of  merit 
Very  important  objective  are  also: 

-  fulfilment  time  contraints  assigned  to  the  programme 

-  not  overcoming  of  ceiling  cost 

-  achievement  of  a  sufficient  "growth  capability" 

The  design  and  development  activities  must  assure  the  achievement  of  the  above  objectives  but,  while  seve 
ral  design  and  development  strategies  can  certainly  guarantee  it,  they  differ  for  the  level  of  fulfilment 
of  the  objectives. 

In  fact  the  objectives  are  intrinsically  opposite;  for  example,  better  effectiveness  (fulfilment  of  Opera 
tional  Requirement)  may  be  achieved  with  higher  installed  weight  and  electrical  consumption,  shorter  deve 
lopment  programme  can  be  realized  at  higher  costs. 

Therefore  project  objectives  are  also  the  order  of  priority  of  the  objectives  and  the  parameter  ratios 
(cost/effectiveness,  time/cost)  to  be  maximized/minimized. 

These  latter  objectives  depend  strictly  upon  the  overall  program  objectives  and  may  very  depending  on  the 
project  requirement,  in  an  updating  programme  the  time  constraints  is  more  important  than  residual  "growth 
capability"  of  the  system,  but  cost/effectiveness  is  always  to  be  minimized. 
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3.  FUNCTIONAL  DESIGN  CONCEPT 

3.1.  Having  established  the  assumptions  and  the  objectives  to  be  achieved  by  the  design  and  development 
programme  of  the  avionic  system  of  the  subject  weapon  system  (tactical  fighter)  related  to  aircraft  charac 
teristics  and  role,  other  objectives,  more  related  to  the  industrial  practice,  are  to  be  fulfilled  to  pro¬ 
ve  the  programme  to  be  successful . 

-  A  design  at  the  state-of-the-art  assures  a  reasonable  life  of  the  system  (even  if  not  so  long  as  for  the 
sirframe)  and  permits  to  find  most  of  the  components  on  the  market. 

-  The  technical  risk  associated  to  the  new  technologies,  at  first  time  introduced  by  the  industry  in  char¬ 
ge  of  the  project,  must  be  consistent  with  overall  programme  objectives  (technological  demonstrator  can 
suffer  higher  development  risk  than  first  line  weapon  system). 

-  Flexibility  of  the  design  allows  easy  implementation  of  required  modifications,  during  system  life  cycle. 

-  Level  of  integration,  redundancy,  standardization  must  be  carefully  investigated  in  relationship  with 
benefits,  risk  and  state-of-the-art. 

-  System  Architecture,  mainly  the  computing  and  internal  data  transmission,  is  related  to  the  above  con¬ 
cepts  and  it  is  of  capital  importance  to  determine  the  potential  evolution  of  the  system. 

3.2.  It  is  assured,  for  the  purpose  of  this  paper,  that  the  basic  functional  components  of  the  project 
are  the  following: 

-  Integration  means  (internal  dats  transmission  system) 

-  Operational  Software  (Mission  related  software  and  computing  devices) 

-  Autonomous  navigation 

-  Assisted  (by  radio  aids)  navigation 

-  Weapon  Aiming 

-  Store  Management 

-  Electronic  Counter  and  Survelliance  Measures 

-  Communication  and  Identification 

-  Display  and  Controls 

-  Interface  with  other  aircraft  systems 

During  detailed  design  and  development  it  is  useful  to  have  an  indication  of  the  level  of  fulfilment  of 
project  objectives  in  relationship  with  different  implementation  of  the  above  functions.  These  indications 
provide  quantization  of  the  value  of  the  alternatives  but  can  also  improve  the  understanding  of  system  cha 
racteristics  and  dictate  functional  design  improvements. 

The  tools  and  methods  of  the  Operations  Research  can  provide  the  means  to  compute  the  required  indications 
to  reach  the  "best"  decision,  that  is  the  decision  with  the  higher  level  of  fulfilment  of  the  contrasting 
design  and  development  objectives. 

In  the  following  paragraph  these  tools  and  methods  are  briefly  described,  bearing  in  mind  that  they  are 
not  directly  finalized  to  the  design  activity  itself  but  the  different  design  selection. 

4.  TOOLS  AND  METHODS 

4,1.  Being  'V'  an  alternative  of  A,  set  of  sll  slternstives  to  be  considered,  it  is  possible  to  asso¬ 
ciate  to  C  («t  ),  that  is  the  action  to  chooae  «<  ,  a  set  of n  numerical  figures: 

fi  <*> ,  ,  ■  • ,  *  r-t*)  ;  h  * 5  a) 

which  describes  quantitatively  all  relevant  information  about  C  ( * ) ,  giving  an  indication  of  the  achieve¬ 
ment  of  each  project  objective  (  i  of  n  )  by  the  action  (Thierauf  R.,  Klekamp  R.,1975). 

Esch  JfL  ( •*• )  can  be  determined  by  means  of  the  Operational  Research  methoda  (mathematical  aimulation,  test 
on  models  or  on  the  real  system,  previous  experience);  when  sufficient  information  is  available,  as  in  the 
case  under  examination,  -y«.  ( •*• )  can  be  expressed  by  a  number. 

It  ia  moreover  defined,  for  esch  objective  (criterium  of  judgement  of  the  action)  a  level  of  acceptabili¬ 
ty  (a  level  not  to  overcome)  L^,  i  «  1,  n,  which  corresponds  to  the  requirement  to  which  the  action  C  (*) 
must  comply. 
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Every  considered  alternative  must  therefore  result  in  an  action  C  («0  f'r  which  is  : 

L;  _  (*.)  >  O  ;  J.  (2) 

This  condition  may  seem  not  immediately  applicable  to  some  objectives,  but  it  has  the  advantage  to  homoge¬ 
nize  the  numerical  indication  trends  of  objective  fulfilment  (also  achievement  of  a  minimum  performance 
can  be  expressed  in  this  way,  for  example  MTBF,  assuming  that  (•< )  is  the  difference  between  the  minimum 
allowed  value  and  the  actual  value,  while  is  zero). 

When  the  n  criteria  (objectives)  to  be  taken  into  account  are  numerous,  it  is  not  easy  to  compare  the  al¬ 
ternatives  by  looking  only  at  the  £  (  *  )  and  therefore  it  is  useful  to  introduce  an  order  of  preference 
in  A. 


Among  various  proposed  approach  to  solve  the  problem  (Roy,  B  ...  1970)  it  has  been  showed  to  be  conve¬ 

nient,  for  the  level  of  definition  and  type  of  system  under  consideration,  to  gather  the  multiobjective 
functions  £  into  a  unique  function. 

First  step  is  to  associate  to  each  objective  (function  )  a  measurement  of  it,  in  arbitrary  units,  with 
relationship  with  a  common  dimension  (the  common  dimension  may  be  related  to  the  resources  required  for 
objective  accomplishment). 

It  means  that  the  problem  is  deterministic  and  therefore  it  is  possible  to  associate  a  value  to  each 
objective,  for  each  alternative  <*  in  A  : 


fit*)] 


=  4 ,  n 


V  oc  e  A 


Function  is  positive  and  non-linear. 
The  multiobjective  function  F  is  : 


FsFHV  F[C(r.)]  ;  l,n  (4) 


Among  a  number  of  function  investigated,  the  simple  additive  function  has  been  proven  sufficiently  sati¬ 
sfactory  and  convenient  for  the  relation  (4). 

Therefore  F  can  be  a  simple  additive  function  : 

f  =  X  ;  yottA  (5) 

and,  being  : 

P-  Lli  -  /  4.--  1,0  Vxfc  A  (6) 


F  becomes  : 

f  x  £  P‘ [Lv  "  ;  V  fc  A 

4*  4 

with  the  following  conditions  : 


(7) 


(B) 


O  t  W,  [L.  -  y.  (<*)]  £1  •  Vli  A  (9) 


Function  F  can  establish  a  complete  ranking  of  preference  in  A. 

4.2.  Nevertheless  F  does  not  solve  completely  our  problem  because,  while  it  gives  information  about  the 
best  alternative,  it  doea  not  indicate  how  the  selected  alternative  is  sensitive  to  the  variation  of  the 
condition  that  determined  its  selection  and  how  the  achievement  of  various  objectives  is  interrelated. 

To  explain,  it  may  be  that  the  "best"  alternative  has  an  effectiveness  strictly  dependent  on  available  in¬ 
dustrial  facilities  and  system  integration  level  while  the  "second"  one  does  not  have  a  such  sensitivity 
and,  for  this  reason,  should  be  preferred. 
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The  function  that  can  give  indication  about  the  above  characteristics  of  the  choice  is  the  "marginal  sub¬ 
stitution  rate"(MSR)  between  the  i-objective  and  a  fixed  criterium  of  reference,  that  is  the  numerical 
value  of  the  i-objective  function  of  the  variation  of  the  term  of  reference. 

The  denomination  "marginal"  points  out  that  the  value  of  the  function  MSR,  for  every  value  of  the  term  of 
reference,  depends  upon  values  of  all  objectives  in  that  point. 

The  criterium  of  reference  may  also  be  another  objective,  in  this  case  the  Marginal  Substitution  Rate  gi¬ 
ves  the  relationship  (in  arbitrary  value  units)  between  the  two  objectives. 

Being  ft  the  variable  associated  to  the  term  of  reference,  the  Marginal  Substitution  Rates  appears  as 
showed  in  figure  1  as  function  of  ft  ,  of  which  (  ft  ) is  theconsidered  implementation. 

Computation  of  MSR'sis  very  difficult  because  it  requires  large  amount  of  information  (including  practi¬ 
cal  knowledge  of  people  who  experienced  similar  situations)  and  great  effort  to  reduce  the  information 
to  the  illustrated  format. 

If  the  MSR's  are  computed  for  each  «  in  A  and  for  all  relevant  criteria  of  reference,  it  is  possibile 
to  compute  a  multidimensional  function  F*,  on  which  the  non  linear  programming  techniques  can  be  applied 
to  determine  the  best  values  of  each  ft  (Mangasarian  0.,  ....  1969). 

The  complexity  of  the  problem  under  consideration  do  not  allow  usually  to  obtain  a  complete  numerical  ex- 
F*;  th.  sji.j4rtsrti oi.  ME  'a  f-r  Aj-stiv^s  m.d 

terms  of  reference,  and  their  comparison  by  means  jf  a  common  measurement  (function  value,  eqt.  3),  can 
be  very  effective  to  show  important  characteristics  of  different  alternatives. 

Computation  of  MSR's  between  objectives  has  also  great  usefulness  in  determining  the  coefficients  p i  in 
equation  (6). 

Application  of  the  above  described  tool  to  a  problem  is  simple,  but  its  effectiveness  depends  greatly 
upon  the  level  of  confidence  of  the  input  information.  To  improve  the  confidence  level  it  is  very  useful 
ar  "fcjetoei-eei "  art,'  fw ,  aotjiwrring  tfte  'Wij# tbifv  o#  mhe  meaBwsmeffft  r,m-'  &  tfie  ee^Lution 

of  the  project;  appropriate  filtering  algorithm  applied  to  the  data  base  improves  the  accuracy  of  measu¬ 
rements  . 

Experimental  implementation  of  this  tool  with  the  related  data  base  is  currently  in  progress  on  a  digital 
computer. 


5.  THE  AVIONIC  SYSTEM  OF  A  TACTICAL  FIGHTER 

5.1.  The  assumptions,  objectives  and  design  concepts  outlined  in  para.  2  and  3  can  be  referred  to  many 
system  and  in  particular  to  the  design  and  development  of  the  avionic  system  of  a  new  tactical  fighter. 

In  this  and  the  following  paragraph,  a  simplified  approach  to  the  problem  to  choose  among  various  system 
design  solutions,  is  summarized ,also  in  order  to  explain  the  use  of  the  tools  and  methods  described  in 
para  4. 

In  spite  of  the  limited  effort  find  limited  amount  of  information,  this  example  provides  indications  co¬ 
herent  with  the  results  of  more  complex  and  time  consuming  analysis  completed  for  similar  systems. 

To  proceed  in  the  analysis  it  is  necessary,  first  of  all,  to  specify  the  values  of  the  various  parameters 
assumed  to  be  significant  to  determine  the  problem  (see  para  2). 

-  Physical  characteristics  are  therefore  assumed  (maximum  weight  may  be  around  400  kg,  air  mass  flow  301b/ 
min  at  40°C,  electrical  power  available  10  Kw  and  so  on). 

-  Parameters  related  to  aircraft  role  are  indicated  (it  is  assumed  a  first  line  weapon  system  ready  for 
series  production  in  48  months  from  go-ahead),  operational  requirements  (weapon  delivery  accuracy,  vul¬ 
nerability,  survivability ,  maintenability ) ,  weapon  inventory  ("iron"  bombs,  A/G  &  A/A  missiles)  and  so 
on. 

-  Industrial  resources  available  for  the  project  are  also  to  be  precisely  specified,  in  term  of  funds, 
manpower,  facilities. 

5.2.  Then  objectives  must  be  specified.  The  objectives  listed  in  para  2.  are  self-explanatory  and  its 
numerical  value  can  be  determined  as  direct  consequence  of  the  assumptions.  Also  design  concepts  of  para. 

3.  should  be  considered  desirable  objectives,  but  a  clear  specification  in  term  of  relevant  design  para¬ 
meters  in  less  straightforward. 

-  State-of-the-art  of  a  design  can  be  regarded  as  the  percentage  of  the  components  (functional  blocks)  cf 
the  system  that  can  be  found,  with  minor  modifications,  on  the  market. 

-  Technical  risk  associated  to  new  technologies  is  related  to  industrial  resources  to  be  allocated  to  as¬ 
sure  a  reasonable  technical  success  probability  to  the  development. 

-  Flexibility,  level  of  integration,  redundancy  and  standadization  are  closely  dependent  on  system  archi¬ 
tecture  and  are  defined  by  parameters  such  as  the  occupancy  of  the  integration  means,  the  memory  storage 
and  computing  capability  available  in  excess  to  the  requirement;  integration  level,  that  is  the  percen¬ 
tage  of  information  flow  available  for  all  system  components;  percentage  of  value  of  system  devoted  to 
shared  functions  (e.g.  data  transmission  interfaces,  controllers);  flexibility, that  is  the  percentage  of  value 


_ Stusuft  ~  - •«» -  .  --  ,  . -  -  _  __  ~  ...  _ — ..■>« ■... 
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be  added  to  the  shared  functions  to  add  a  new  capability  to  the  system  (e.g.  cost  of  modification  of 
the  avionics  to  include  a  new  weapon  to  the  weapon  inventory). 

5.3.  Now  a  functional  design  of  the  avionic  system  can  be  outlined  and  the  numerical  indicators  (  yi , 
v(p  . ...  y*  )  of  objectives  and  acceptability  levels  (  L^,  Lg,  ....  Ln)  can  be  computed. 

For  purpose  of  comparison  three  solutions,  based  upon  the  functional  partitioning  identified  in  para.  3.2., 
are  considered. 

ril  St  s.lutivii  o,  o  \  ,i  Ty^yc'  n;  i.&  uu£  .  o  Uilluiiui  A— —  C*  VI  6iiSiiixo&W)i  sy¬ 
stem,  a  single  central  mission  computer,  a  low  level  of  integration,  function  implemented  in  digital /ana¬ 

log  technology. 

Design  type  B  is  based  on  a  dual  redundant  time  multiplexed  data  bus  (MIL-STD-1553  B  type),  duplex  central 
mission  computer  and  partially  distributed  computing,  high  level  of  integration  and  digital  implementation 
of  system  functions. 

Design  type  C  has  a  multiplexed  data  bus,  fully  distributed  computing,  very  high  level  of  integration  (all 
functions  fully  integrated),  all  digital  implementation  of  functions. 

.c  1  ufre.*  .. ,  v  .<.7.’, e  ‘.-L^eA.  re  c  tc  1  nft  (SR  1  1  '  e-ei.rc 

that  are  levels  not  to  be  exceeded). 

5.4.  The  multiobjective  function  F  is  now  computed  starting  from  parameters  of  table  1,  by  computing 
values  ar  i  (see.  eqt.  3)  and  coefficients  p^  (eqt.  6),  called  weights;  results  are  showed  in  table  2. 

Values  obtained  for  the  multiobjective  function  indicate  as  less  adeguate  the  system  type  A,  while  the 
slight  difference  between  the  preferred  types  (B  and  C)  is  well  within  the  precision  6  of  the  method, 
that  in  this  case  can  be  extimated  to  be  £  =  0.050. 

Others  considerations  are  required  to  choose  between  B  and  C,  these  considerations  are  illustrated  in  the 
following  paragraph. 

6.  CRITICAL  FACTORS 

The  Marginal  Substitution  Rates  (MSR,  described  in  para.  4.2.)  are  computed  for  a  more  detailed  investiga¬ 
tion  of  avionic  system  type  B  and  C  (see  para.  5). 

6.1.  Variations  of  assumptions  result  in  MSR  having  an  external  term  of  reference.  For  example,  availa¬ 
ble  industrial  resources  variation  induces  corresponding  MSRs  of  the  most  important  parameters  (remaining 
parameter  are  not  affected  or  the  MSR  is  not  computable)  that  are  shown  in  fig.  2  for  system  B  and  fig.  3 
for  system  C. 

The  variation  of  the  industrial  resources,  funds,  manpower,  facilities  are  expressed  in  coraerctional  units 
of  cost,  being  250  the  value  assumed  for  the  analysis  of  para.  5,  while  MSR's  are  expressed  in  unita  of 
value;  remember  thst  an  higher  value  corresponds  to  a  better  situation  (value  of  technical  risk  one  means 
no  risk) . 

Variation  of  multiobjective  function  F  against  the  reference  parameter  0  variation,  for  the  considered 
objective,  ia  shown  in  table  3.  It  appears  clearly  that  availability  of  industrial  resources  is  a  very 
critical  factor  for  solution  C. 

6.2.  The  relationship  between  objectives  is  clearly  shown  by  MSR  that  has  as  term  of  reference  the  value 
of  an  objective.  These  MSR's  indicate  the  impact  on  the  syatem  when  an  objective  does  not  fully  schleve 
the  design  target. 

It  is  o^ubiUo,  6u  ui.  ex8uu}yxb  of  Ci  ltB.'lum  ul  ,  bit.  tuft  ,  .twg,  av.uu  ib.t,  oi  tub  wjroV£fli,  ill  lig.  4  (sy¬ 
stem  type  B)  and  fig.  5  (system  type  C)  are  showed  the  corresponding  MSR's  for  system  effectiveness  (Ope¬ 
rational  Requirement  fulfilment),  cost  and  flexibility.  All  indicators  are  measured  in  units  of  value,  re- 
'JMt  WP  MU  M  or  644  seid  V,  tyyotWI,  o?  vtftfc 

grstion  level  value  do  not  necessarly  correspond  on  equal  vslue  of  MSR. 

Partial  varistion  of  the  multiobjective  function  F  against  the  referenced  parameter  variation  is  shown  in 
table  4.  Again  system  type  B  is  less  sensitive  to  the  varistion  than  system  C,  for  which  the  achievement 
of  the  desired  integration  level  is  a  critical  factor. 

6.3.  According  to  the  indications  given  in  thia  paragraph  and  in  para.  5,  a  deaign  of  type  B  can  be  con¬ 
sidered  leas  critical  to  be  implemented  for  its  lower  sensitivity  to  project  conditions  and  therefore  it 
ia  preferred  with  assumed  importance  for  development  risk;  nevertheless  it  is  to  be  noted  that  deaign  C 
can  show  better  cost/effectiveneas  ratio  and  this  feature  could  induce  to  prefer  type  C  if  its  importance 
increases . 


7. 


OPERATIONAL  SOFTWARE  DEVELOPMENT  : AN  EXAMPLE 


Among  the  functional  componenta  of  the  avionic  syatem  listed  in  para.  3.2,  there  is  the  Operational  Soft¬ 
ware,  the  on-board  Software  directly  related  to  aircraft  mission  (including  data  transmiasion  software 
but  not  the  equipment  embedded  software /firmware,  like  symbol  generation  Software  in  displays,  signal  ela¬ 
boration  in  radar  etc . ) . 

In  this  paragraph  the  Operational  Software  Development  Process  will  be  examinated,  utilizing  the  tools  de¬ 
scribed  in  para.  4.  and  particularly  the  MSR's  to  find  out  the  critical  factors  affecting  it  (system  type 
B  of  para.  5.  is  assumed). 

7.1.  Assumptions. 

-  The  Development  process  under  examination  starts  from  the  finalization  of  the  Specification  of  the  Soft¬ 
ware  (also  called  Operational  Flight  Program,  OFP)  and  enda  when  the  Software  itself  haa  been  verified 
and  validated  on  the  real  airborne  computer  in  isolation  on  ground  (integration  with  the  rest  of  the  sy¬ 
stem  is  considered  part  of  another  procesa). 

-  The  target  computer  for  the  software,  that  is  the  on-board  computer  of  the  avionic  system,  is  a  state- 
of-the-art  equipment  with  aufficient  computing  capability  (200  K  Iatr/s,  thousands  of  Wheatstone  Instruc 
tion  per  second)  and  available  memory  (96  K  byte). 

-  The  available  toola  to  support  the  development  process  are  : 

a)  a  mainframe  host  computer  with  the  following  characteristics 

.  available  computing  power  1,000  K  Iatr/s  (thousands  of  Wheatsone  instructions  per  second) 

.  central  memory  1  M  byte,  available  fast  masa  memory  300  N  byte 
.  6  working  stations  (video  terminals) 

.  complete  set  of  peripherals  (line  printer,  magnetic  tape  drivers  etc.) 

b)  a  test  station  for  the  airborne  equipment  program  verification  and  performance  evaluation. 

c)  a  complete  set  of  programs  to  assist  the  programmers  in  preparation,  debugging  and  validation  of  the 
Operational  Software. 

-  The  airborne  equipment  (mission  computer)  and  the  support  tools  are  mature  and  proven. 

-  An  amount  of  64  K  byte  of  memory  are  foreseen  for  the  Operational  Software;  programming  in  high  order- 
language  by  six  senior  analysts  and  eighteen  skilled  programmers  is  scheduled  in. 24  months;  exhaustive 
specification  and  assistance  by  four  system  engineers  are  available. 

-  Documentation  of  activity  and  program  to  be  produced. 

7.2.  Objectives 

-  Production  of  the  required  Operational  Software  within  the  available  time  and  fulfilment  of  the  Specifi¬ 
cation. 

-  Minimization  of  cost  and  technical  riak  (defined  aa  the  probability  to  exceed  time  constraints). 

-  Not  exceed  a  total  loading  of  75%  for  the  hoat  computer. 

-  Maximization  of  personnel  (analysts  and  programmers)  productivity. 

-  Maximization  of  program  validation  effectiveneaa. 

-  Not  exceed  a  total  time  loading  of  70%  and  a  memory  occupancy  of  64  K  byte  for  the  airborne  computer. 

7.3.  Objective  fulfilment  indicators  are  then  computed  with  extensive  use  of  Operations  Research  tools 
and  previous  experience  (for  example,  a  ratio  of  70/30  between  ahort  and  long  computer  instructions  deter¬ 
mines  the  number  of  instructions  in  64  kbyte  of  program,  an  average  cost  per  instruction  of  100  $  permits 
cost  calculation,  an  average  programmer  production  of  100  instructions  per  month  is  assumed). 

The  results  are  summarized  in  table  5.  For  an  immediate  result  evaluation  the  indicators  and  acceptability 
levels  do  not  exactly  follow  the  definition  of  eqt.  (2),  but  they  can  eaaily  reduced  to  them. 

Examination  of  table  5  gives  a  number  of  immediate  indications  of  some  critical  aspects  of  the  process. 

-  Programming  in  high  order  language  is  assumed  and  it  results  evident  that  this  ia  essential  for  the  de¬ 
velopment  process.  In  fact  a  ratio  in  the  range  of  6:1  can  be  considered  for  the  ratio  between  number  of 
instructions  programmed  in  high  order  and  assembly  language  and  therefore  time  constraints  cannot  be 
achieved  with  the  available  number  of  analysts  and  programmers.  Increase  available  personnel  does  not 
solve  the  problem  because  it  also  increase  the  multiprogramming  level  and  saturate  the  host  computer  (see 
for  example,  Bradbury  D  ...,  1978),  increase  cost,  risk  and  decrease  significantly  the  validation  effec¬ 
tiveneaa  . 

-  The  low  productivity  (70%)  indicates  a  possible  reduction  of  the  number  of  analysts  and  programmers  with 
low  impact  on  the  other  objectives. 
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7.4.  To  find  out  critical  factors  of  the  development  process  a  MSR  analysis  is  performed. 

-  Variation  in  the  maximum  level  of  multiprogramming  of  the  host  computer.  It  is  a  synthesis  of  all  compu¬ 
ter  characteristics  (computing  power,  central  and  mass  memory,  operating  system  characteristics)  and, 
for  the  purpose  of  table  5,  it  was  assumed  equal  to  six. 

This  level  can  be  increased  or  decreased  assuming  a  different  hardware  implementation  or  variation  of 
computer  resources  assigned  to  the  software  development  activity. 

In  figure  6  MSR's  computed  against  multi  programming  level  variation  are  shown,  remember  that  MSR's  are 
interdependent.  Host  computer  resources,  that  has  impact  on  the  number  of  contemporary  users,  appears 
to  be  an  high  critical  factor  for  Software  Development  process,  particularly  for  fulfilment  of  time  con¬ 
straints. 

-  Finally  figure  7  snows  risk  and  productivity  MSR's  against  airborne  computer  utilization.  This  objective 
does  not  have  a  critical  factor  to  the  above  objectives  achievement. 

In  the  same  way  all  other  factors  can  be  examined  and  their  impact  on  the  software  development  process 
evaluated. 
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8.  .CONCLUSIONS 

•  ’£~Lr  ~  - 

■'iSn  operational  analysis  tool  to  assist  in  understanding  complex  system  features ,4tae-  ■  been— il-lua tro ted ._ 
Application  to  the  design  and  development  of  the  avionic  system  of  a  tactical  fighter  hoo  beerr,describedr<_ 
with  special  regard  to  critical  factors  affecting  the  system  development  or  part  of  it. 

It  is  pointed  out  that  the  described  tool^dee^  no't^Be  used  to  design  or  develop  the  system,  which  requires 
much  more  complex  activities,  but  it  is  a  possible  useful  way  to  summarize  and  present  the  results  of  the 
Operations , -Research  in  order  to  trim  the  project  in  the  right  direction. 

ul f  ul  t  tuwal  J  SJs.’te,,,  upTiK.izati.ua,  Caal iKai  a ti U..  Jut  il.i  liwi.  ai.o  JtValOpii.vaT  ti  ajj-utfs  can  t  ; 
made  by  means  of  the  .Marginal  Substitution  Rate  factors. 

.  y  C kfitf 

Applicationlof  the  above  tools  and  techniques  has  been  done  and  is  currently,  done  for  systems  similar  to 
the  examples^ -tike  the  development  of  the  avionic  system  of  AM-X  aircraft-and  for  other  military  aircraft 
projects.  The  obtained  results  show  the  validity  of  the  approach  and  encourpges  its  application  also  in 
future  projects. 
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B 
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Physical  Char. 
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2. 

Operat.  Req. 
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Time  Constr. 
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Growth.  Cap. 

50 

30 

30 

20 

H 

Flexibility 

10 

9 

2 

1 

TABLE  1 

System  design  indicators  (  )  in  arbitrary  units  for  three 

different  avionic  system  alternatives. 
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art 
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1 
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m 
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1 
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■a 
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0.2 
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1 

8. 
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0.1 

0.4 

0.4 

0.6 

K3 

Flexibility 

0.15 

0.1 

aaaaaanmmi 

0.8 

0.9 

■ 

Value  of  F 

0.430 

0.590 

0.600 

TABLE  2 


Values,  weights  and  multiobjective  function  for  three  different 
avionic  aystem  alternatives. 


A  $ 

type  B 

type  C 

-50 

-0.023 

-0.050 

+50 

+0.028 

+0.040 

TABLE  3 


F  partial  variation  assuming  resources  variation 


TABLE  4 

F  partial  variation  assuming  integration  level  variation 
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Multiobjective  function  F  «  0.410 


20 
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5% 


70* 
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TABLE  5 


Kultiobjective  indicators  for  Software  Development  Process 
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Marginal  Substitution  Rate  functions 
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MSR's  for  Host  Computer  Multiprogramming  level  variation 
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MSR's  for  Airborne  Computer  Utilisation  variation 
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ABSTRACT 


^5>The  Advanced  Fighter  Technology  Integration,  AFTI/F-16  Program  is  developing  and  flight  validating 
advanced  technologies  which  improve  fighter  lethality  and  survivability.  The  capability  is  achieved  by 
the  integration  of  mission  task  tailored,  digital  flight  controls  with  a  director-type  fire  control 
system  and  advanced  target  sensor/trackers  into  an  automated  maneuvering  attack  system. 

The  core  technology  in  the  AFTI/F-16  approach  to  this  integrated  system  capability  is  the  Digital 
Flight  Control  System  (DFCS).  Integrated  with  the  on-board  avionics  system,  the  DFCS  provides  capabil¬ 
ities  for  maximum  exploitation  of  flight/fire/weapon  control  and  other  subsystem  integration. 

Task  automation  as  applied  to  the  fighter  mission  will  be  evaluated  with  AFTI/F-16 ’ s  Automated 
Maneuvering  Attack  System  (AMAS).  Radar  and  FLIR/Laser  sensor/trackers  provide  precise  targeting 
information  in  AMAS  for  both  air-to-air  and  air-to-surface  attack.  Careful  attention  is  given  the 
pilot/vehicle  interface  through  multi-function  displays,  wide  field-of-view  HUD,  predictive  HUD 
symbology  and  Khands-on*  controllers.  Voice  Command  is  anticipated  to  be  a  key  interface  feature.  The 
AMAS  is  expected  to  allow  accurate  weapon  delivery  from  low  altitudes  rfbelow  160nrJ5*ihile  achieving 
increased  survivability  through  maneuverability,  the  low  altitude  environment  and  stand-off  delivery.^ 

Flight  testing  of  the  DFCS  began  at  Edwards  AFB  in  August  1982.  Flight  testing  of  AMAS,  including 
ordinance  delivery,  will  be  conducted  in  1984-85. 

The  paper  expands  on  the  systems  approach  to  the  DFCS,  avionics  architecture,  redundancy  considera¬ 
tions,  attack  sensor  integration,  coupling  of  flight  and  fire  control  systems,  weapon  integration,  crew 
station  provisioning  and  automation  concepts. 


ACRONYMS  AND  ABBREVIATIONS 


OE/CIS 


Air-To-Air 

Air-To-Surface 

Advanced  Development  Program  Office 

Advanced  Fighter  Technology  Integration 

Above-Ground-Level 

Automated  Maneuvering  Attack  System 

Avionics  Multiplex  Data  Bus 

Built  In  Test 

Central  Air  Data  Computer 

Data  Entry/Cockpit  Interface  Set 

Digital  Flight  Control  System 

Display  Multiplex  Data  Bus 

Electronic  Warning 

Fire  Control  Computer 


*  Deputy  Program  Manager,  AFTI/F-16  Advanced  Development  Program 
**  Automated  Maneuvering  Attack  System  Chief  Engineer 


SU-i 


FCS 

Flight  Control  System 

FUR 

Forward  Looking  Infrared 

FOR 

Fleld-of-Regard 

FOV 

Field-of-View 

9 

Acceleration  Due  to  Gravity 

HUD 

Head-Up  Display 

HMS 

Helmet  Mounted  Sight 

I8U 

Independent  Backup  Unit 

IFFC 

Integrated  Flight  and  Fire  Control 

IFIM 

In-Flight  Integrity  Management 

INU 

Inertial  Navigation  Unit 

LARAP 

Low  Altitude  Radar  Auto-pilot 

LOS 

Line-Of-SIght 

MFDS 

Multi -Function  Display  Set 

MTBF 

Mean  Time  Before  Failure 

OFP 

Operational  Flight  Program 

PVI 

Pilot/Vehicle  Interface 

RALT 

Radar  Altimeter 

S/T 

Sensor/Tracker 

SAIF 

Standardized  Avionics  Integrated  Fuzing 

SWIM 

System  Wide  Integrity  Management 

TF/TA/OA 

Terrain  Following/Terrain  Avoidance/Obstacle  Avoidance 

TMD 

Tactical  Munition  Dispenser 

TSE 

Target  State  Estimate 

VCS 

Voice  Command  System 

VHSIC 

Very  High  Speed  Integrated  Circuit 

WAAM 

Wide  Area  Anti -Armor  Munition 

WMUX 

Weapons  Multiplex  Data  Bus 

1.  AFTI/F-16  PROGRAM  DESCRIPTION 

The  overall  objective  of  the  Advanced  Fighter  Technology  Integration  ( AFTI )/F-16  Advanced  Develop¬ 
ment  Program  Is  to  develop  and  flight  validate  technologies  which  will  Improve  fighter  lethality  and 
survivability.  The  AFTI/F-16  program  provides  for  the  development.  Integration,  flight  evaluation  and 
demonstration  of  emerging  technologies  applicable  to  fighter  aircraft  In  the  critical,  tactical  environ¬ 
ment  of  low-altitude  attack  and  air-to-air  combat.  This  Is  a  joint  program  involving  the  United  States 
Air  Force,  Navy,  Army  and  the  National  Aeronautics  and  Space  Administration  (NASA).  The  AFTI/F-16 
Advanced  Development  Program  Office  of  the  Flight  Dynamics  Laboratory  serves  as  the  responsible  develop¬ 
mental  agency.  General  Dynamics,  Fort  Worth  Division,  Is  the  principal  contractor  responsible  for 
system  development.  The  Air  Force  Flight  Test  Center  and  NASA  Dryden  Flight  Research  Facility,  sup¬ 
ported  by  General  Dynamics,  are  responsible  for  flight  test  operations. 

The  AFTI/F-16  development  is  being  accomplished  In  two  phases  Involving  two  periods  of  aircraft 
modification  and  two  series  of  flight  tests.  The  Digital  Flight  Control  System  (DFCS)  is  the  core 
technology  and  as  such  Is  the  primary  technology  development  task  In  Phase  I  of  the  program.  The  DFCS 
development  addresses  flight  path  control  and  provides  task-tailored,  multimode  control  for  operational 
versatility.  The  DFCS  enables  efficient  use  of  6  degree-of-freedom,  decoupled  aircraft  control  Involv¬ 
ing  direct  force  modes  and  weapon  line  pointing.  This  part  of  the  AFTI/F-16  program  includes  develop¬ 
ment  of  the  demonstrator  aircraft,  with  provisions  for  direct  force  control  and  weapon  line  pointing, 
cockpit  development,  avionics  system  integration,  voice  command  evaluation  and  basic  provisions  for 
interface  and  Installation  of  the  Automated  Maneuvering  Attack  System  (AMAS)  hardware.  The  July  1982  to 
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June  1983  flight  test  period  will  be  accomplished  to  assess  and  validate  the  Phase  I  te''hr"'1  ogles.  In 
Phase  II,  automated  maneuvering  attack  is  the  key  thrust  in. demonstrating  increased  weapon  delivery 
effectiveness  and  survivability.  The  DFCS  is  coupled  with  a  director-type  fire  control  system.  Target 
sensors/trackers,  helmet  sight  and  weapons  interface  automation  are  added.  A  key  thrust  is  the  evalua¬ 
tion  of  automation  with  respect  to  weapon  delivery  tasks.  Flight  testing  is  planned  for  the  February 
1984  to  March  1985  period. 


2.  PHASE  I  -  DIGITAL  FLIGHT  CONTROL  SYSTEM  (DFCS) 

First  flight  of  the  AFTI/F-16  was  successfully  completed  on  10  July  1982  (Figure  1).  This  signifi¬ 
cant  milestone  in  the  development  of  the  AFTI/F-16  Phase  I  Digital  Flight  Control  System,  was  preceded 
ij  i  jtjr  t  Tljtrow.  1-e-Etlr.g  tc  v^lW&Se  TsTdwirt.  computer  scttwwH..  !he  sfreraft  wa*  ‘evriti? 
General  Dynamics/Carswell  AFB  TX  to  Edwards  AFB  CA  and  entered  flight  testing  that  will  continue  to 
June  19B3. 


Figure  1  AFTI/F-16  First  Flight  -  20  July  1982 


ruoHT  Tin  julv  mu  to  juw  mi 


The  AFTI/F-16  DFCS  (Figure  2)  Is  an  advancement  of  the  current  state-of-art  for  digital  flight 
control.  The  combination  of  computer  hardware  associated  software  and  failure  management  techniques 
make  it  possible  to  use  a  tri-channel  versus  conventional  quad-channel  flight  control  system  architec¬ 
ture.  Advanced  redundancy  management  techniques  provide  essentially  two  fail-operate  capability, 
achieving  a  reliability  equivalent  to  one  loss-of  control  in  10'  flight  hours  and  one  mission  abort  in 
106  flight  hours. 


The  Bendix  BDX  -930  computers  employ  "pipeline"  architecture,  16-Bit  micro-processors  and  operate 
together  in  an  asynchronous  mode.  The  advantages  of  decreased  cost  of  ownership,  weight  and  electrical 
power  without  compromise  of  system  reliability  are  expected  for  the  triplex  redundant  system.  The 
design  feature  of  identical  software  residing  In  each  computer  is  another  driver  in  reduced  ownership 
cost. 


Figuie  2  AFTI/F-16  Phase  I  -  Digital  Flight  Control  System  (DFCS) 
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Flight  testing  to  date  is  demonstrating  that  the  digital  flight  control  design  goals  are  being  met. 
Highly  reliable  operation  is  being  demonstrated;  supporting  analytical  studies  and  laboratory  data 
indicate  at  least  a  25  percent  mean-time-between-failure  (MTBF)  improvement  in  the  triplex  digital 
system  vs  a  quad  digital  system.  With  respect  to  quad  analog  system,  a  2  to  4  times  improvement  in  MTBF 
is  indicated.  The  software  intensive,  triplex  redundancy  management  design  works;  analytical  studies 
indicate  at  least  a  20  percent  life  cycle  cost  savings  for  the  triplex  versus  quad-digital  flight 
control  system.  Viability  of  flight  control/avionics  communication  via  multiplex  data  busses  has  been 
established.  The  multi-bus  avionics  architecture  and  software  configurable  system  supports  growth  to 
automation  functions  and  enhanced  mission  performance  features.  These  will  be  flight  demonstrated  in  an 
Automated  Maneuvering  Attack  System  during  the  Phase  II  of  the  AFTI/  F-16  Program  (1984-1985). 

A  feature  of  the  DFCS  is  task-tailored  multimode  flight  control  laws  including  the  6  degree-of-freedom, 
decoupled  modes.  This  multimode  control  capability  is  a  ten-fold  increase  over  the  F-16  analog  flight 
control  capability.  All  the  modes  have  been  demonstrated.  Power  approach  control  laws  show  a  signifi¬ 
cant  improvement  over  the  standard  F-16.  Maneuver  quickening  and  increased  precision  in  flight  path 
(for  bombing)  and  pointing  (for  gunnery)  control  have  been  demonstrated  through  the  unique  multimodes. 

The  automated  maneuver  flaps  show  cruise  and  maneuver  performance  improvement. 

The  AFTI/F-16  cockpit  development  has  obtained  excellent  acceptance  by  the  pilots.  The  wide  angle, 
fce'l-v  in  be  cunfAmfl  raaCf  f  r  mfteHin  lmI ,  aulti^kr  cke  diftflejs  ffi r 

an  effective  pilot  interface  for  avionics  and  flight  control  systems. 

On  22  Dec  1982,  the  first  flight  test  of  a  voice  command  system  was  conducted  on  the  AFTI/F-16.  We 
believe  that  Voice  Command  could  have  significant  potential  for  reducing  pilot  workload  in  single-seat 
fighter  circraft.  However,  first  the  technology  must  be  matured  such  that  the  word  recognizer  can 
reliably  function  in  the  harsh  noise,  vibration  and  'g*  environment.  Current  testing  of  the  voice 
command  system  is  aimed  at  this  goal.  Functional  utilization  of  voice  command  needs  further  work  to 
define  appropriate  applications.  We  hope  to  evaluate  those  in  Phase  II  of  the  program  (1984-1985). 


3.  PHASE  II  AUTOMATED  MANEUVERING  ATTACK  SYSTEM 

In  this  phase  of  the  AFTI/F-16  program,  capabilities  of  the  core  digital  flight  control  system  are 
exploited  to  demonstrate  mission  performance  improvement  through  task  automation.  Through  software 
integration,  the  attack  sensors,  flight  control,  fire  control,  pilot  vehicle  interface  and  weapons 
interface  are  integrated  into  the  Automated  Maneuvering  Attack  System  (Figure  3). 

Integrated  flight  and  fire  control  (lFft)  technology  is  key  to  this  development.  With  ifK,  a 
control  loop  is  closed  between  the  fire  control  and  flight  control  systems;  couplers  are  designed  to 
automatically  null  weapon  aim  error.  Full  authority  of  the  digital  flight  control  system  is  available 
in  the  AMAS. 

The  potential  of  IFFC  technology  for  improved  weapon  delivery  has  been  vividly  demonstrated  in 
flight  test  on  the  IFFC  F-15.  While  introduction  of  IFFC  technology  into  fighter  aircraft  offer  signif- 
IW  U  'i'  nfetpi  <.%' '  ft'.U'.t/  r  To  tMJirt 

usability  of  IFFC  in  real-world  combat  conditions.  The  AFTI/F-16  AMAS  development  focuses  system 
integration  and  task  automation  for  combat  application.  Thus,  the  Integrated  system  design  must  be 
driven  by  the  combat  scenarios.  (Figure  4). 


Figure  3  AFTI/F-16  Phase  II  -  Automated  Maneuvering  Attack  System  (AMAS) 
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Figure  4  AFTI/F-16  AMAS  Combat  Scenarios 


Combat  Scenarios 


An  immediate  need  is  for  improved  capability  in  fighter  aircraft  to  fly  low,  day  and  night,  and  in 
weather,  using  terrain  for  cover  from  enemy  defenses.  AFTI/F-16  Phase  II  addresses  this  need  in  the 
logical  first  step  of  day  attack;  provisioning  for  extension  of  the  technology  to  night  attack  is  also 
considered.  In  addition,  all-aspect  air-to-air  gun  combat  is  a  goal  for  exploitation  of  the  Automated 
Maneuvering  Attack  System. 

Air  to-Surface.  The  AFTI/F-16  has  the  systems  to  demonstrate  precision,  low  altitude  air-to-surface 
maneuvering  attack.  Figure  5  illustrates  a  maneuvering  attack  scenario.  The  pilot  expects  to  fly  fast, 
low  (under  100m,  use  terrain  masking,  maneuver  with  freedom  and  remain  head  out-of-cockpit.  Today, 
requirements  of  this  attack  profile  create  work  loads  the  impose  intolerable  demands  on  the  pilot;  the 
timeline  is  highly  compressed  and  ground  clobber  is  a  significant  concern  while  managing  sensors  and 
weapons.  Here  automation  can  be  logically  applied,  reallocating  tasks  that  saturate  the  pilot's  atten¬ 
tion  and/or  are  beyond  human  limitations.  The  aim  is  to  free  the  pilot  to  concentrate  on  target 
acquisition/identification,  attack  planning  and  threat  avoidance,  with  the  automated  system  working  the 
flight  trajectory,  altitude  control  and  attack  guidance  tasks. 

The  AMAS  system  is  designed  such  that  flight  path  control  from  engagement  on  ingress  through  weapon 
release  and  into  egress,  can  be  fully  automatic.  Automatic  guidance  is  provided  for  both  the  set-up  and 
actual  weapon  delivery.  However,  the  pilot  can  intervene  at  anytime,  adjusting  either  the  ground  track 
or  altitude  profile  of  the  delivery  to  suit  terrain  or  threat  conditions.  He  can  select  semi-auto  and 
manual  control  options. 

The  AMAS  enables  accurate  weapon  delivery  while  maneuvering.  Bombs  can  be  delivered  from  level, 
diving  or  lofted  turning  attack  that  provides  standoff  distance  from  the  target  and  minimizes  exposure 
to  ground  threats.  To  complement  the  maneuvering  delivery,  active  control  of  a  digitally  fuzed  Wide 
Area  Anti -Armor  Munition  (WAAM)  tactical  munition  dispenser  (TMD)  can  be  accomp’ished;  fuze  settings 
are  automatically  updated  at  the  moment  of  weapon  release  rather  than  being  pre-set  at  takeoff. 

The  maneuvering  attack  scenario  drives  design  requirements  to  allow  precision  tracking  of  fixed  and 
mobile  targets.  The  key  for  accurate  automatic  weapon  delivery  is  knowing  precise  target  location.  On 
AFTI/F-16,  target  location  is  provided  through  radar  and  FLIR/Laser  sensor/trackers  and  inertial  naviga¬ 
tion  unit  ( INU)  coordinate  information.  A  helmet  mounted  sight  is  used  for  sensor  slewing  to  accomplish 
rapid  off-boresight  target  designation.  Very  wide  field-of-regard  is  desired  for  sensors,  including  the 
ability  to  look  up,  back  and  down,  to  enable  freeaom  of  maneuvering  without  sensor  breaklock. 

Air-to-Air.  In  the  air-to-air  scenario  (Figure  6)  an  all-aspect  gun  envelope  is  the  demonstration  goal. 
With  IFFC,  high  line-of-sight  rate  and  front  quarter  engagements  become  realistic.  This  was  vividly 
demonstrated  with  the  PQM-102  drone  kill  by  the  IFFC  F-15.  AMAS  will  extend  this  capability  by  exploit¬ 
ing  the  full  AFTI/F-16  capabilities:  full  authority  digital  flight  control,  advanced  flight  modes  and  a 
low  noise  FLIR/Laser  sensor.  An  improved  hit  probability,  over  an  aggregate  of  high  angle  off  (front 
quarter),  high  line-of-sight  rate  and  dynamic  tail  chase  encounters,  is  anticipated.  Automation  is 
applied  in  sensor  management,  flight  path  avoidance  and  for  nulling  aim  errors.  An  automatic  collision 
avoidance  maneuver  and  auto-trigger  are  also  software  design  considerations.  Here  too,  extreme  wide 
field-or-regard  for  sensors  is  desired.  Excellent  sensor  clutter  rejection  is  needed  to  minimize  target 
break-lock.  Low  "noise"  sensor  tracking/ranging  is  desired  to  reduce  filter  lags  in  the  fire  control 
computations  and  facilitate  tracking  in  highly  dynamic  engagements. 

Demonstrator  Configuration 

Figure  7  illustrates  the  AMAS  demonstrator  configuration.  Equipment  added  to  the  Phase  I  -  DFCS 
demonstrator  Include  the  FLIR/Laser  sensor/tracker  (S/T)  set,  360  deg>*ee  roll  coverage  radar  altimeter. 
Standardized  Avionics  Integrated  Fuzing  (SAIF)  and  helmet  mounted  sight. 


The  FLIR/Laser  was  chosen  because  of  the  excellent  clutter  rejection  and  day/night  capability. 
Special  attention  was  given  to  minimize  aircraft  performance  loss  and  to  provide  the  required  wide 
field-of-regard.  The  sensor/tracker  set  was  functionally  partitioned  such  that  only  essential  sensor 
functions  are  provided  by  the  externally  mounted  head  unit;  target  state  estimator,  tracking,  fire 
control  and  environmental  control  functions  are  provided  by  internally  housed  aircraft  equipment.  The 
toiifv/rmsl  stroke  monrrt  at, <5  small  sensor  fend  ji  mutter  [uuiiitir#!  JdaiQ  mtnfwiits  way  ovtr  the  e^crtlii.y 
mach  range;  supersonic  performance  is  not  sacrificed  with  thedual  sensor  head  installation. 

The  above-ground-level  (AGL)  altitude  hold  autopilot  operates  on  a  system  altitude  derived  from  the 
sensor  compliment  of  radar  altimeter,  fire  control  radar,  the  sensor/tracker  and  the  inertial  navigation 
unit.  The  radar  altimeter  measures  current  altitude  with  full  (360  degree)  roll  attitude  capability 
praidri  bj  multiple  Ljabined  with  ihe  ther  tensor  dats,  i  ufe  fuL  si t i tud  tel-  ,  r  fi’e  it 

generated  through  the  digital  flight  control  system.  The  purpose  of  this  autopilot  mode  is  to  reduce 
pilot  workload  ,  allowing  the  pilot  to  pay  additional  attention  to  target  .acquisition  during  ingress,  in 
the  Edwards/Nellis  AFB  flight  test  environment.  This  is  not  a  full  terrain-following  system.  However, 
we  consider  automatic  terrain  following/terrain  avoidance  to  be  an  important  requirement,  and  another 
critical  technology  need,  for  operational  employment  of  AMAS  with  night/all  weather  a  :tack  capabilities. 
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Figure  8  AFTI/F-16  AMAS  Approach  To  Weapon  Delivery  System  Integration 
System  Architecture 

The  AMAS  system  architecture  was  developed  to  provide  proper  functional  partitioning,  minimal 
interface  parameters,  and  minimal  system  transport  delay  to  maximize  system  performance  and  integration 
efficiency.  As  shown  in  Figure  9  the  system  is  structured  around  three  MIL-STD-1553  digital  multiplex 
busses  that  provide  the  majority  of  the  subsystem  communications.  These  MUXs,  Avionics  (AMUX)),  Display 
(DMUX),  and  Weapons  (WMUX),  operate  with  a  basic  50Hz  rate  and  have  a  primary  and  backup  bus  controller. 
Subsystems  have  been  partitioned  between  tne  AMUX  and  DMUX  busses  to  provide  for  a  well  balanced  bus 
loading.  Inertial  data  in  analog  form,  for  axis  transformations,  are  some  of  the  few  parameters  not 
carried  by  the  MUX  bus  structure. 
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Figure  9  AMAS  Multi-Bus  Architecture 
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Modifications  to  existing  operational  flight  program  software  are  required  for  the  flight  control 
system,  the  fire  control  computer,  stores  management  set,  head-up-display,  multi -function  display  set 
in  f  Wte  Fiet  ewrtfc!  ■WiStt,  figwre'IO  Msl-i  Falwtiwil  MMgnmefrti  *i  **j1;»*  WH  iyUaii  0(V« . 
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Figure  10  Functional  Allocation  To  AMAS  OFP's 


System  Design 


The  functional  partitioning  of  the  AMAS  system,  illustrated  in  Figure  11,  was  developed  through 
consideration  of  interface  conditions,  proliferation  of  OFP  changes  from  a  single  system  modification, 
data  transport  delays,  system  reliability,  and  system  safety.  The  air-to-surface  modes  are  designed  to 
operate  in  the  low  altitude  attack  regime  that  requires  flexible  target  acquisition,  accurate  target 
tracking,  low  altitude/high  bank  angle  flight  conditions  and  high  load  factor  turning  delivery 
algorithms.  Figure  12  illustrates  design  approaches  to  each  of  these  requirements.  The  air-to-air  mode 
is  designed  with  a  director  fire  control  solution  nulled  by  the  decoupled  flight  control  system  that 
provides  high  angle-off  gun  firing  opportunities  and  a  maneuvering  target  tracking  capability. 


Figure  11  AMAS  Functional  Partitioning 


Sensor/Tracker 


The  AMAS  sensor/tracker  is  being  procured  by  General  Dynamics  from  Westinghouse  Corporation.  The 
sensor  Is  an  8  to  11,5  micron  FUR  with  three  selectable  fields-of-view.  It  generates  525  raster  line 
video  that  is  displayed  on  the  pilots  multi-function  displays.  The  video  tracker  has  both  correlation 
and  centroid  track  capabilities  with  auto  acquisition  and  adaptive  gates.  The  laser  is  a  Neodynium  Yag 
1.06  micron  laser  with  a  variable  pulse  rate  and  beam  diffusion.  It  also  provides  a  quadrant  track 
capability  to  enhance  FLIR  lock-on.  The  sensor/tracker  provides  a  full  120  degree  field-of-regard  with 
no  vignetting  and  in  the  dual  sensor  aircraft  configuration  has  no  aircraft  obscuration.  The  target 
state  estimator  in  the  sensor/tracker  is  a  nine  state  Kalman  filter  with  variable  gains  structured 


around  a  platform  axis  system.  The  sensor/tracker  has  seven  major  modes  of  operation  (Figure  13)  and  is 
primarily  commanded  by  the  fire  control  system. 


TA  RGET  A  COUISITION 

HMS  PERMITS  LARGE  OFF  BORESIGHT  ANGLE  DESIGNATIONS 
RADAR  ALLOWS  STANOOFF/NIGHT  TARGET  ACQUISITION 
HUO  PROVIDES  ACCURATE  LOW  OFF  ANGLE  DESIGNATIONS 
PREPLANNED  TARGET  OR  TARGET  OF  OPPORTUNITY  OPTIONS 


ACCURATE  TARGET  TRACKING  WITH  SENSOR/TRACKER 

LARGE  OFF  BORESIGHT  ANGLE  TRACKING  (120») 

ACCURATE  LASER  RANGING  AT  LOW  ALTITUDES 
TARGET  IDENTIFICATION  AT  LONGER  RANGES 
MECHANIZATION  OPTIMIZED  FDR  LOW  ALTITUDE  DELIVERIES 


LOW  ALTITUDE/HIGH  BANK  ANGLE  OPERATION 

IFIM,  SWIM  DESIGNED  FOR  LOW  ALTITUDE  OPERATION 

LOW  ALTITUDE  RADAR  AUTOPILOT  INCLUDED  TO  REDUCE  PILOT  WORKLOAD 

360°  ROLL  COVERAGE  FROM  RADAR  ALTIMETER  FDR  HIGH  BANK  ANGLES 


HIGH  G  TURNING  DELIVERY  ALGORITHMS 

DESIGNED  FOR  MAXIMUM  INGRESS  MANEUVER  FLEXIBIILTY 
AUTD  INGRESS  STEERING  FOR  TURNING  DE  LIVERY  SET  UPS 
AUTOMATED  3D  TURNING  BOMBING 

Figure  12  AMAS  Low  Altitude  Design  Features 
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Figure  13  AFTI/F-1 6  Sensor/Tracker  Modes 


Fire  Control  System 


The  fire  control  system  provides  several  essential  elements  in  the  AMAS  system:  the  sensor  manager, 
the  air-to-air  director,  the  curvilinear  or  turning  bombing  director,  ingress  steering  and  collision 
avoidance  determination. 

The  sensor  manager  function  monitors  the  on-board  avionics  sensor  complement  to  insure  their  integ¬ 
rity  and  that  sensor  support  is  adequate  for  the  closed  loop  Integrated  flight  and  fire  control  opera¬ 
tion.  The  sensor  manager  also  determines  system  altitude  (above  ground  level)  from  the  sensor  comple- 
ment(a  minimum  of  two  sensors  is  required)  to  furnish  to  the  low  altitude  hold  autopilot.  The  antenna 
switching  for  the  360  degree  bank  angle  radar  altimeter  is  also  accomplished  by  the  fire  control 
computer. 

The  air-to-air  director  algorithm  Is  of  second  order  and  is  based  on  a  closed  form  solution  of 
bullet-time-of-fl ight  for  the  20MM  projectile.  The  original  curvilinear  bombing  algorithm  used  in 
design  of  the  IFFC  F-15  system  has  been  modified  to  increase  weapon  delivery  accuracy.  A  predetermined 
release  range  is  established,  by  the  pilot,  and  the  algorithm  establishes  the  aircraft  load  factor  and 
bank  angle  to  culminate  in  a  weapon  delivery  at  that  range.  Ingress  steering  is  also  provided  that  will 
generate  a  path  to  setup  a  curvilinear  attack  regardless  of  where  the  target  is  located  at  the  time  of 
system  engagement. 

Collision  avoidance  is  calculated  for  both  air  combat  and  ground  avoidance.  The  ground  avoidance 
calculation  considers  the  aircraft  speed,  attitude,  altitude,  and  load  factor  capability.  In  any 
automated  air- to- surface  operation,  this  algorithm  is  active  and  will  trigger  an  automated  fly  up  to 
provide  a  safe,  selectable  floor  under  the  aircraft's  operation. 


In  the  AMAS  system  the  triple  redundant  flight  control  system  contains  the  IFFC  couplers  and  control 
laws  that  implement  the  fire  control  system  consnand  or  error  signals,  the  self  contained  fly  up,  and  the 
System  Wide  Integrity  Management  (SWIM)  manager. 

The  flight  control  couplers  take  the  fire  control  signals  and  convert  them  into  signals  compatible 
with  the  AFTI/r -16  inner  loop  control  laws  (i.e.-load  factor,  Ditch  rate,  roll  rate,  yaw  rate).  The 
ob-lv-e;.  „vuKleT*  tuKt.  lilt  (.fieri CUJ  uS«utf>  uri*i  MlA&t.t  at.4  iin-rtfil  gwn 

rate  and  generate,  through  a  proportional  plus  derivative  control  loop,  inputs  to  the  DFCS  decoupled 
flight  control  laws.  The  flight  control  system  attempts  to  null  the  errors  and  match  the  predicted  gun 

(ate.  11  eVcft'l Oil  errors  ait  uuiltd  thTirayii  uuJy  baVs  yitcli  rot  nitre  oZnnatti  tTTtTr.  etr.  Tral'eG  Wrftrayi. 

roll  rate  and  yaw  rate  motions. 

The  bombing  couplers  accept  bank  angle  and  load  factor  commands  from  the  fire  control  system.  These 
r/cnianJS  n.  j£ri  Tlttlli  mndifiration  +n  makp  thpm  accp,tphlp  to  thp  fli  ht  control  system's  decou  led 
control  law  structure.  All  the  couplers  provide  rate  and  magnitude  limits  for  safety  and  redundancy 
management  considerations. 

The  System  Wide  Integrity  Management  (SWIM)  function  (Figure  14)  is  to  insure  that  the  system 
condition  is  acceptable  for  engagement  and  operation  in  the  selected  closed  loop  IFFC  mode  and  if  not, 
to  disallow  or  terminate  the  engagement  in  a  safe  manner.  The  SWIM  final  decision  is  always  accom¬ 
plished  in  the  Flight  Control  System  (FCS).  The  redundant  nature  of  the  FCS  makes  it  most  suitable  as 
Tf.t  $Wflt  manager.  h.  acufUm,  uais  teed-vci  ffom  subsystems  if'i&vn.  It),  Wit  rtrif 

contained  checks  and  system  crosschecks  to  verify  proper  operation  or  status. 


Figure  14  System  Wide  Integrity  Management  (SWIM) 
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Figure  15  In-Flight  Integrity  Management 
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System  Safety 

Several  system  safety  design  features  have  been  incorporated  into  the  AMAS  system  design.  A  sutmtary 
of  these  features  is  presented  in  Figure  16.  Engage  and  disengage  requirements  must  be  satisfied  in  the 
triple  redundant  flight  control  system.  Additionally,  the  pilot  always  has  control  override  authority 
and  multiple  disengagement  options.  To  provide  a  safe  floor  for  all  air-to-surface  operations,  the 
automated  fly-up  is  provided  upon  exceeding  the  ground  avoidance  criteria  or  upon  experiencing  a  system 
failure  state  within  prescribed  altitude  regions.  Aircraft  structural  protection  is  also  provided  by 
the  inner  loop  control  laws  of  the  flight  control  system. 
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Figure  16  System  Safety  Design  Features 


Pilot/Vehicle  Interface 


The  AFT I /AMAS  cockpit  displays  and  controls  have  been  optimized  to  decrease  pilot  workload  and 
Increase  his  efficiency  during  the  AMAS  weapon  delivery  mission  phases.  The  cockpit  front  panel 
(Figure  17)  provides  three  multi -function  displays  and  a  HUD  with  display  symbology  designed  for  the 
AMAS  missions.  All  pilot  actions  during  the  attack  phase  are  thru  hands-on  switches  on  the  throttle  or 
the  side  stick  controller.  Mission  phase  selection  Is  provided  by  pressing  a  single  button  on  the  HUD 
control  panel.  In  the  air-to-surface  low  altitude  regime  the  pilot  must  be  presented  predictive 
displays  as  to  the  aircraft  attack  trajectory  and  release  conditions  as  well  as  the  weapon  delivery 
solution.  Figure  18  shows  the  HUD  symbology  for  the  AMAS  attack  profiles.  The  predictive  profile  is 
displayed  towards  the  left  side  of  the  HUD;  the  attack  symbology  is  displayed  in  the  center.  The 
predictive  display  shows  the  predicted  flight  trajectory  (start,  current  position,  apex,  release)  and 
weapon  release  conditions  (dive  angle,  release  and  recovery  altitudes).  The  attack  symbology  displays 
the  load  factor  and  bank  angle,  both  coitmanded  and  actual,  to  achieve  the  desired  release  conditions. 
This  symbology  is  amenable  to  manual  as  well  as  automated  attacks.  The  wide  field-of-vlew  (15  X  20 
degree  Instantaneous)  facilitates  placement  of  this  symbology  on  the  HUD.  The  two  upper  multi-function 
displays  present  sensor  video  as  well  as  system  status  and  control.  Video  from  the  FLIR  or  radar 
sensor/trackers  can  be  selected  by  the  pilot,  hands-on,  at  anytime.  Target  designation  and  cursor 
corrections  are  easily  accomplished  through  these  displays.  The  lower  display  is  a  Tactical  Situation 
Display  featuring  a  moving  map  (film  reader)  format  to  assist  in  target  Ingress  and  egress. 
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VERTICAL  PLANNING 


ATTACK  STEERING 


Figure  18  AMAS  Predictive  Display  Sumbology 


Helmet  Sight. 

A  significant  part  of  the  AMAS  system  is  a  helmet  sight  that  will  enable  rapid  head-up  and  hands-on 
off-boresight  target  designation.  This  feature  is  considered  essential  in  order  to  reduce  pilot  work¬ 
load  to  a  level  where  the  AMAS  weapon  delivery  can  be  effectively  accomplished  in  a  single-seat  fighter. 
The  pilot  looks  at  the  target  of  interest,  pushes  the  "designate"  button  on  his  sidestick  controller, 
and  the  sensors  will  slew  to  the  designated  direction;  he  can  expect  a  coarse  sensor  lock-on  (target  can 
be  found  within  the  sensor  video  field-of-view).  Precise  correction  to  target  designation  would  then  be 
made  through  a  throttle-mounted  cursor  control  or  voice  command  with  MFD  sensor  video.  Reverse  cueing 
of  target  location  (e.g.  -  locked-on  sensor)  is  also  possible  with  the  helmet  sight  to  assist  the  pilot 
in  visual  acquisition  of  the  target. 

Voice  Coirmand. 

Another  dimension  to  an  interactive  pilot/vehicle  interface  is  through  voice  command.  Careful 
attention  was  given  in  designing  hands-on  controllers  for  AFTI.  However,  the  number  of  switches  and 
functions  (Figure  19)  have  reached  the  limit  of  reasonable  operability.  Voice  can  be  the  next  threshold 
in  cockpit  operation,  giving  the  fighter  pilot  a  true  head-up,  hands-on  control  capability  and  reducing 
or  redistributing  pilot  workload.  Voice  may  be  a  key  element  in  sirgle-seat  operation  of  a  fighter  on 
an  AMAS-type  mission  scenario.  Unfortunately,  we  do  not  know  at  this  time  if  additional  voice  comnand 
efforts  beyond  Phase  I  will  be  funded  for  Phase  II  -  AMAS  evaluation. 


REQUIREMENT!:  HANOS-ON/HE AD-UP  CONTROL 


TOD  A  Y  -  Apptotchmg  Limitt  of 
Hsnds-On  Control l*rt 


•  THROTTLE  •  SIDESTICK  CONTROLLER: 


*  MUlTIf  URCT10R  DUPLAY: 


TOMORROW  -  Vote*  Inttrtctin*  Control 

Augmmtt  HtnrAOn  Control 


•  FUNCTIONS: 

•  SENSOR  CONTROL 

•RMp.FUR/Imk... 

•  STORES  NANAI EMERT 

•  Willi  SMwlFmMq... 

•  ELMHT/FIRE  CONTROL  MOOES 

•  DEFENSIVE  SYSTEMS  OPERATION 

•  CWLFNnl... 


m COTTONS 
pH*  FUNCTIONS 


•  ENHANCES: 

•  SMSLE  SEAT  OPERATIONS 

•  ALLWEATHER  UMSM  NS 

•  RISNT  ATTACK  NNMNS 


Figure  19  Voice  Cocisnand  -  The  Next  Step  in  Cockpit  Operations 
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4.  AUTOMATION  GROWTH 

The  AFTI/F-16  program  represents  a  step-by-step  development  process  that  could  rationally  lead  to  a 
single-seat  night  attack  demonstration  (Figure  20).  The  DFCS  development  provided  a  base  with  which  to 
automate  the  flight  path  control  function.  In  AMAS,  the  low  altitude  radar  autopilot  (LARAP)  simulates 
a  terrain  following  capability  in  a  near  flat  earth  environment.  The  real  need  is  for  fully 
automatic/redundant  terrain  following/terrain  avoidance/obstacle  avoidance  (TF/TA/OA)  that  can  ensure 
safe  low-altitude  (below  100m)  high-g  turning  flight.  We  believe  that  through  multiple,  complementary 
sensor  data  correlation  (e.g.  -  agile  beam  radar,  CO,  laser  radar,  full-roll  radar  altimeter,  stored 
terrain  data  base),  with  careful  attention  to  systenrsafety  and  the  pilot-vehicle  interface,  this 
c'dpabl  1  tty  can  bt  available  day  a  id  night.  In  utolt  t  i  efftcVfvtVy  ai-cuinplisti  tlve  i_omp i HtieiftaTy  Oats 
correlation,  Very  High  Speed  Integrated  Circuit  (VHISC)  technology  becomes  a  requirement.  A  helmet 
display  with  head-driven  FLIR  imagery  could  be  an  essential  technology  for  pilot  confidence. 

Automation  of  the  navigation  function  is  an  equally  significant  task.  In  a  joint  effort  with  the 
U.S.  Army,  AFTI/F-16  is  planning  to  evaluate  a  stored  data  base,  digital  moving  map.  The  digital  map 
can  increase  situational  awareness  during  TF/TA  flight  and  through  terrain  correlation  could  provioe 
autonomous  precision  navigation.  The  digital  map  display  could  also  function  as  a  tactical  situation 
display  locating  threat  lethality  envelopes  and  survivable  corridors.  Further  application  could  be  made 
for  optimum  route  planning,  using  terrain  masking,  threat  penetration  and  time  of  arrival  information. 
Complementary  systems  such  as  JSTARS  (Joint  Surveillance  and  Target  Attack  Radar  System)  become  an 
important  adjunct  for  providing  real-time  targeting  information  with  the  auto-nav  functions. 

Automation  of  the  engagement  function  is  the  key  area  addressed  by  AMAS;  auto  attack  steering  and 
nign-g  turning  weapon  delivery  is  me  thrust.  in  me  oay,  a  neimec  signt  can  De  usea  Tor  Largec  oesig- 
nation.  At  night  and  in  weather,  an  automatic  target  recognition  capability  becomes  very  important. 

Head  directed  night  vision  and  FLIR  devices  with  the  helmet  sight/display  could  be  useful. 

Automation  in  the  weapons  area  is  addressed  in  AMAS  with  the  Standardized  Avionics  Integrated  Fuzing 
(SAIF)  for  area  munitions.  The  weapons  MUX  bus  with  MIL  1760  interface  compatibility  can  provide 
automatic  fuzing  and  controlling  capabilities  for  a  variety  of  unguided  and  guided  weapons. 


Figure  20  Potential  Growth  To  Night  Attack  Capability 


5.  CONCLUSION 

In  conclusion,  we  believe  that  the  AFTI/F-16  Automated  Maneuvering  Attack  System  development  Is  an 
Important  approach  for  development  of  the  Integration  technologies  and  will  provide  an  engineering 
perspective  that  forms  a  valuable  base  on  which  to  build.  We  recognize  that  AFTI/F-16  AMAS  is  not  an 
end  product,  but  Is  an  Invaluable  flight  research  tool  with  which  to  build  and  sort  the  benefits  of 
combat  automation. 


DISCUSSION 


J.F.Irwin,  Ca 

( 1 )  Shouldn’t  the  Horizontal  Situation  Display  (HSD)  be  moved  up  in  the  HUD  Control  space  to  optimize  the 
Head-Up/Head-Down  transition  problem? 

(2)  During  low  altitude  TF/TA  weapon  delivery  the  pilot  should  maintain  a  head  up  attitude:  A  head  up  FL1R 
implementation  would  be  a  good  subject  for  near  term  evaluation. 

(3)  How  is  the  360°  Doppler  Altimeter  implemented  in  the  antenna  configuration  and  how  is  switching  from  one 
to  another  implemented? 

Author's  Reply 

(1)  1  agree  the  HUD  central  panel  is  a  terrible  waste  of  valuable  cockpit  display  space.  However,  the  current  HUD 
design  would  preclude  moving  the  HSD  up,  even  if  cost  did  not.  Maybe  that  plate  displays  of  the  future  will 
make  your  idea  feasible;  or,  a  helmet  display  may  obviate  the  need  for  a  HUD. 

(2)  LANT1RN  does  have  a  raster  HUD  for  FL1R  display.  We  would  like  to  do  work  in  this  area,  but  it  is  not  in  the 
current  program. 

(3)  The  360°  Radar  Altimeter  is  implemented  with  four  antenna  pairs  located  around  the  aircraft,  i.e.  top,  bottom 
and  both  sides.  The  fire  control  computer  performs  the  antenna  switching  based  on  aircraft  roll  attitude.  The 
aircraft  roll  attitude  is  derived  from  the  Inertial  Navigation  Unit  that  is  closely  monitored  by  the  redundant 
flight  control  system. 

W.H.McKinlay,  UK 

It  would  be  interesting  to  know  how  the  system  handles  discontinuities,  e.g.  when  the  pilot  intervenes  and  takes  over 
manual  control  or  wishes  to  regain  an  automatic  profile,  going  from  manual  to  automatic. 

Author’s  Reply 

The  pilot  can  override  the  automated  system  at  any  time.  During  these  periods  of  pilot  override  the  fire  control 
equations  are  continuously  calculated  using  the  present  aircraft  flight  conditions.  When  the  pilot  releases  the  control 
back  to  the  automated  system  through  reduced  stick  forces,  the  automated  system  has  a  correct  weapon  delivery 
solution  from  the  aircraft  current  position  and  tilght  conditions. 

P.Bied-Charreton,  Fr 

(1 )  With  the  electro-optical  pod,  do  you  plan  to  make  air-to-air  tracking,  in  conjunction  with  radar,  for  instance  for 
target  identification? 

(2)  HUD:  If  the  need  for  wide  angle  (holographic)  HUD  is  only  to  present  more  data  in  the  FOV  edges,  why  spend 
so  much?  Would  it  be  simpler  and  cheaper  to  have  20  by  20  degrees  real  HUD,  and  put  the  data  in  other  HDD 
(level  display)?  Then  the  need  is  only  for  20  degrees  TV  raster/stroke  HUD,  possible  combined  with  helmet 
mounted  sight. 

Author’s  Reply 

We  are  not  specifically  working  on  target  I.D.;  however,  our  narrow  field-of-view  FL1R  can  give  about  a  10  X  tele¬ 
scope  to  assist  target  l.D.  In  air-to-air,  sensor  management  (radar  +  FL1R)  is  automatically  following  target 
designation.  The  AFT1/F-16  HUD  is  20°  x  25°  conventional  optics.  With  a  HDD,  the  eye  must  focus  inside  the 
cockpit  -  an  advantage  for  the  HUD  where  symbology  focus  is  at  infinity.  We  believe  that  helmet  displays  have 
potentials.  Bulk  and  weight  of  current  designs  somewhat  inhibit  use  in  the  high  ‘g’  fighter  environment,  although 
some  cursory  testing  shows  that  this  is  not  an  overwhelming  problem. 


J. Mitchell,  UK 

In  order  to  increase  night  attack  capability  have  you  considered  the  use  of  pilot’s  night  vision  goggles,  or  if  not,  what 
was  the  reason? 

Author’s  Reply 

They  are  currently  not  in  the  programme  although  certain  people  have  considered  them.  The  current  programme  is 
day-only.  We  hope  to  continue  the  technology  development  to  night  attack.  This  task  would  include  to  consider 
goggles  and/or  helmet  display  devices. 
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GMaureau,  Fr 

Concemant  l’amdlioration  d’efficacite  en  combat  qui  peut  resulter  de  l’amelioration  des  visualisations  integrees  dans 
le  systeme,  est-il  exact  de  dire  que  vous  la  recherchez: 

-  d’abord,  par  l’emploi  d’un  viseur  de  casque  permettant  d’accrocher  rapidement  des  senseurs  sur  la  cible 

—  ensuite,  en  ce  qui  conceme  le  ’’Head  Up  Display”,  plus  a  partir  d’une  modernisation  du  “software”  et  de  la 
symbologie  associee,  que  par  un  elargissement  relatif  de  son  champ? 

Author’s  Reply 

The  helmet  sight  provides  rapid  sensor  (radar  and/or  FL1R)  cueing  (off-boresight)  to  obtain  target  designation. 
Sensor  control  is  then  automatic  with  the  pilot  flying  convergence  to  where  the  automatic  system  can  then 
complete  the  precision  weapon  delivery  task.  Helmet  displays  are  believed  to  have  additional  merit  for  head- 
out-of-cockpit  operation  in  the  future  -  this  is  not  currently  in  the  AFTI/F-16. 


-  The  wide  FOV  HUD  accommodates  spreading  of  symbology  to  make  it  more  usable  to  the  pilot.  It  should  be 
rmttf  that  ir  sn*J><IT  A- A  ^omry  nr^  uitnunarirg  \-S  rftt.vt.  IS  Mpt  rrr>  tkJ  k Kir  WIT  F-c  V 
until  the  last  few  seconds.  A  larger  combiner  glass  does  not  significantly  improve  the  pilot  aiming  capability 
for  this  situation.  Again,  the  advantage  is  for  providing  space  for  “planning”  data  to  allow  the  pilot  to  manage 
his  weapon  delivery  task. 


G.Hunt,  UK 

The  AFT1  system  appears  to  be  inherently  rather  costly.  The  philosophy  advocated  in  the  Keynote  Address  is 
towards  a  reduction  in  Avionics  Cost.  Your  comment  would  be  appreciated. 

Author’s  Reply 

First  the  triplex  digital  flight  control  system  represents  an  approach  for  LCC  savings  (min.  hardware  for  2  fail- 

f  operate  capability)  over  other  analogue  and  Tgital  approaches.  Plus,  it  provides  a  magnitude  increase  in  mission- 

canabilitv  throueh  software  integration.  Second,  what  is  the  measure  of  cost?  Reducing  avionics  will  certainly 
reduce  cost  -  but  will  it  put  bombs  on  target  and  can  you  survive?  Combat  losses  are  very  costly,  as  it  is  not  to 
achieve  mission  goals.  AFTI  aims  at  improving  survivability  through  the  automatic  techniques  (stand  off  weapon 
delivery,  low  level  attack,  turning  delivery,  etc.)  AFTI  also  aims  at  increased  delivery  effectiveness  (killing  targets) 
including  use  of  low  cost,  “dumb”  bombs  and  cannon. 


.  Finally,  we  can  all  agree  on  the  need  to  reduce  avionics  costs.  I  have  heard  many  good  ideas  for  so  doing  during  this 
meeting.  But  this  does  not  necessarily  mean  to  reduce  avionics  capability.  Mission  requirements  are  extending  to 
night  and  all  weather  operations  with  even  increasing  threat  capabilities.  We  must  achieve  the  capability  to  do  the 

■MkHKpOniitfiU  -  Uwrt  to  !*•'■  ft  rtf  Kmpt}  mprtoUt 

One  afterthought  -  AFTI  is  not  a  prototype.  It  is  a  technology  testbed,  research  vehicle  for  sorting  ideas  cn  how 
to  best  do  the  perceived  job. 

R.Westley,  Ca 

Concerning  “Voice  Command”,  could  you  comment  on  the  size' of  the  vocabulary  required  in  voice  command  and 
the  present  outstanding  problems  of  voice  command  in  the  AFTI  cockpit? 

\ 

Author’s  Reply 

Current  system  in  test  has  36  word  vocabulary,  but  we  are  using  only  about  1 0  words  for  test  efficiency.  Specifica¬ 
tion  for  future  system  would  not  likely  exceed  200  words.  Use  of  syntax  will  help  limit  size  of  vocabulary  needed. 
Need  to  keep  vocabulary  required  of  pilot  to  be  simple,  easy  to  use  and  flexible  —  not  rigid  in  format  and  process. 


Another  aspect  is  the  FL1R  sensor  integration  approach.  Both  A  and  A-S  capabilities  are  maintained  (censor 
field-of-regard  and  aircraft  performance)  in  the  single  airplane.  Maximum  use  is  also  made  of  on-board  aircraft  sub¬ 
systems,  rather  than  duplicating  functions  in  a  bolt-on  pod.  Only  essential  unique  sensor  functions  are  packaged 
with  the  sensor  head. 
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SUMMARY 

' 

^  Modern  fighter  aircraft  carry,  beside  various  tvpes  of  bombs^  more  and  more  '‘intelli¬ 
gent^  weapons.  In  this  context  the  development  of  a  Stores  and  Missile  Management  System 
has  to  take  into  account  the  requirement  from  the  operational/tactical  considerations  as 
well  as  the  optimal  usage  of  advanced  electronic  equipment  together  with  a  growth  and 
adaption  capability  in  both  areas.  On  the  basis  of  existing  weapon  delivery  systems  this 
paper  discusses  some  possible  trends  in  weapon  development  (i.  e.  more  intelligent  fire- 
and-forget  missiles)  and  weapon  control  systems  development  (i.  e.  Mil-Bus  1553  B,  pro¬ 
grammable  weapon  management  computer)  together  with  the  integration  problems  of  a  com¬ 
plete  aircraft  weapon  delivery  system  from  the  planning  stage  via  equipment  and  subsystem 
development  to  rig  and  on-aircraft  testing  up  to  first  flight  test  experiences.  V 


Fig.  1 :  Weapon  System  Tornado 


1 .  INTRODUCTION 

The  weapon  history  has  been  strongly  influenced  bv  milestones  as  the  development  of 
gun-powder,  tanks,  aircraft  and  submarines  or  Radar  and  Electronic  Counter  Measures  durinq 
WWII. 

In  our  days  this  trend  proceeds  with  increasing  speed.  New  developments  aim  for  faster, 
less  detectable,  more  manoeverable  aircraft  and  are  overall  more  and  more  equipped  with 
electronic  systems  enabling  the  crew  to  fly  and  navigate  under  adverse  weather  conditions 
using  automatic  terrain  following  or  terrain  avoidance  systems  with  navigation  accuracies 
up  to  some  meters  using  updating  procedures,  GPS  or  JTDS.  The  cost  of  the  electric/elec¬ 
tronic  equipment  more  and  more  exceeds  the  pure  aircraft  costs. 

Not  only  the  bombs  require  a  more  sophisticated  release  system  but  also  the  addition  of 
highly  intelligent  missiles  add  to  the  complexity  of  the  overall  Weapon  Delivery  System. 
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CURRENT  STATUS  OP  WEAPON  DELIVERY  SYSTEMS 


The  weapon  delivery  system  of  a  modern  fighter  aircraft  consists  mainly  of  the  fol¬ 
lowing  subsystems:  (see  Fig.  2) 

Stores  Management  Systems  (SMS) 

Gun  Control  System 
Missile  Management  System 

Interface  Avionic/Computer/Displays  and  Controls 


2 . 1  The  SMS 


Before  take-off  the  ground  crew  has  to  program  the  available  and  loaded  weapons  into 
the  SMS  which  is  normally  done  through  dedicated  codes.  Special  self-testing  circuits  are 
checking  whether  the  programmed  load  is  compatible  with  the  conditions  on  the  closed  bomb 
racks  andwhether  the  load  is  acceptable  for  reasons  like  loading  symmetry  or  aerodynamic 
clearance. 

Shortly  before  take-off  the  bomb  racks  are  equipped  with  cartridges.  Already  now 
the  crew  can  decide  on  different  weapon  packages  for  preplanned  attacks  to  be  stored  in 
the  SMS  for  immediate  use.  In  an  automatic  release  mode,  this  attack  package  information' 
is  sent  to  the  Main  Computer  which  in  return  produces  release  cues  at  the  appropriate 
time  intervals  to  give  the  required  ground  spacing. 

The  SMS  will  then  distribute  the  release  signals  and  initiate  the  release. 

Beside  this  automatic  mode  the  manual  mode  is  maintained  to  be  used  depending  on 
operational  requirements  or  equipment  failure. 

An  additional  special  mode  for  the  SMS  is  the  emergency  jettison  which  cleares  the 
aircraft  from  all  external  stores  in  the  shortest  possible  time  in  cases  of  emergency. 

Important  design  criteria  for  the  SMS  are: 

'  No  unwanted  fuzing  or  release  of  a  weapon  by  defect  of  a  single  component. 

0  No  inhibition  of  the  emergency  jettison  function  by  defect  of  a  single 
component . 

°  Only  reduced  but  not  inhibited  operability  of  the  system  by  defect  of  a 
single  component. 


High  flexibility  for  adaption  of  new  weapon  types. 


Although  a  gun  in  a  modern  aircraft  would  appear  to  be  an  old  fashioned  relic, most 
fighter  aircraft  still  carry  gun  systems  for  an  air/ground  role  or  for  a  short-range  air/ 
air  combat.  The  main  differences  to  former  times  are  the  increased  caliber,  increased 
firing  speed  of  several  hundred  rounds/minute  and  improved  projectile  velocities. 

Guns  are  still  installed  in  modern  aircraft  because  of  several  advantages  over  A/A 
missiles: 


also  useable  for  short  range  combat  ("dead  area"  for  missiles) 

aircraft  with  guns  is  still  armed  although  all  missiles  have  been  fired 

comparing  installation/ammunition  costs  for  guns  with  missiles,  guns  are 
very  cost  effective 

guns  are  also  useable  against  ground  targets 

The  gun  System  is  controlled  and  preselected  via  the  SMS  through  «  Cun  Control  Unit. 

In  a  two-man  cockpit,  usually  the  pilot  is  in  control  over  this  system,  using  direct  visual 
contact  and  the  HDD. 

2.3  The  Missile  Management  System  (MMS) 

An  increasing  important  role  for  the  overall  weapon  system  is  taken  by  the  MMS. 

It  nowadays  consists  of  several  units  dedicated  to  the  special  missiles. 

23.1  Alr/Alr  Missiles 


Air/Air  missiles  are  usually  controlled  by  the  pilot.  The  pilot  activates  the  mis¬ 
siles  seeker  head  (either  Radar  or  I/R),  waits  for  a  lock-on  information  (audio  tone  or 
HUD  aiming)  and  fires  the  missile,  activated  through  the  SMS  and  the  Air/Air  Missile 
Unit. 

2.3.2  Air/Ground  Missiles 


Air/Ground  or  Air/Ship  missiles  are  usually  used  in  preplanned  attacks  and  mostly 
controlled  by  the  navigator  in  a  two-man  cockpit,  because  of  the  complex  nature  of  weapon 
aiming,  arming  and  navigation.  Seeker  heads  may  be  controlled  by  TV,  I/R,  Laser,  Radar 
homing,  or  active  Radar.  The  actual  firing  is  initiated  through  the  SMS  and  the  relevant 
missile  interface  unit. 

A/G  missiles  with  TV  or  I/R  seeker  head  (i.  e.  Maverick)  can  be  controlled  from  the  air¬ 
craft  normally  only  during  the  aiming  phase.  When  a  target  lock-on  has  been  achieved 
(shown  i.  e.  on  a  TV  monitor),  the  missile  is  beeing  fired  and  keeps  the  target  picture 
as  accurate  as  the  crew  was  able  to  insert  during  the  lock-on  phase  (fire-and-forget 
missile) . 

Sharacteristic_gointsj:  Distance  to  target  relatively  small  (high  risk) ,  not  useable  in 

bad  weather  conditions,  for  Laser  guided  missiles  a  separate  Laser 
designator  is  neccessary,  aircraft  break-away  after  firing. 

A/G  missiles  with  Radar  homing  devices  are  used  as  a  counter  measure  against  hostile 
Radars.  Presently  these  missiles  are  more  adapted  for  use  against  preplanned  targets. 

They  approach  the  target  with  high  speed  to  avoid  the  detected  Radar  being  switched  off 
again.  There  is  also  a  possibility  for  a  usage  where  the  missile  is  launched  into  the 
expected  area  and  is  '  then  waiting  on  a  parachute  for  the  hostile  Radar  to  be  switched 
on. 


A/G  missiles  with  active  Radar  head  (i.  e.  Exocet,  Kormoran)  get  their  target  in¬ 
formation  from  the  aircraft  Radar  already  far  outside  the  missile  firing  range  (see 
Fig.  2)  and  the  Ground/Ship  defence  distance.  The  aircraft  then  can  approach  the  target 
from  a  different  direction  under  the  Radar  horizon  and  is  then  either  firing  the  mis¬ 
sile  within  its  range  without  any  further  updating  (lower  hit  probability),  or  is  very 
shortly  coming  over  the  Radar  horizon  for  a  data  update  before  firing.  In  both  cases 
the  aircraft  is  still  outside  the  ground/ship  defence  area  during  its  break-away  and 
escape  manoever.  The  missile  itself  is  flying  as  low  as  possible  and  only  initiating  its 
active  Radar  shortly  before  reaching  the  target  for  final  target  aiming  (especially  for 
moving  targets. 


HiUh  hit  probability,  low  risk,  useable  under  all  weather  con- 
ditions,  aircraft  break-away  after  firing 


1  Aircraft  rises  above  radar  horizon  of  the  target 

2  Input  of  target  into  the  navigation  system  of  the  aircraft 

3  Approach  from  below  radar  horizon 

4  Maximum  mission  range 

5  Launch 

6  Fire  and  forget 

Fig.  3:  Typical  technology  progress 


PREDICATED  TECHNOLOGY  PROGRESS 


The  coming  years  will  bring  a  continuing  progress  in  all  aspects  of  technology. 
Fig.  4  shows  the  development  progress  in  view  of  data  processing  problems. 
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Fig.  4:  Technology  Progress  in  Data 

Processing 

The  technology  progress  in  all  ECM  matters  (see  Fig.  5)  is  strongly  linked  to  the 
weapon  aspects.  This  link  will  get  stronger  in  future  when  direct  connections  exist  bet¬ 
ween  the  ECM  system,  the  Main  Computer  and  the  Weapon  Control  System. 
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Fig.  5:  Technology  Progress  ECM 

All  the  above  predictions  are  influencing  the  planned  concepts  for  future  aircraft 
and  also  the  necessary  effort  for  starting  a  development  or  integration  test  programme. 


4.  DEVELOPMENT  OF  AN  INTEGRATED  WEAPON  DELIVERY  SYSTEM 

In  former  times  WW  1  weapons  were  carried  on  an  aircraft  by  adaption,  no  special 
measures  were  taken  during  aircraft  development  to  optimize  the  interface  to  the  weapons 
or  to  make  the  weapon  delivery  more  efficient.  This  view  has  changed  considerably  and 
nowadays  the  planning  effort  for  the  weapon  delivery  system  (WDS)  already  starts  during 
the  development  phase  of  the  aircraft.  All  components  of  the  WDS  have  to  follow  defined 
rules  in  terms  of  qualification  requirement,  standardized  data  transmission  links,  cable 
connectors  or  others.  Equipment  and  subsystem  development  is  controlled  to  follow  the 
above  rules  and  finally  leads  to  an  integrated  rig  test  facility  where  all  the  require¬ 
ments  can  be  checked  under  simulated  conditions  up  to  a  stage  where  the  WDS  for  the  first 
time  is  fully  operable  in  the  prototype  aircraft. 

Very  often  it  is  not  a  complete  new  system  or  aircraft  to  be  developed  but  only  parts 
of  it.  The  principle  idea  is  still  that  already  the  development  of  the  equipment  should 
be  controlled  (or  very  well  defined)  to  enable  an  optimal  adaption  of  the  single  equip¬ 
ment  into  the  WDS. 

An  example  of  such  an  integration  and  test  facility  is  shown  in  Fig.  6. 


Fiq.  6:  Riq  facilitv  for  integration 
and  test 


V  . 


CONCEPT  FOR  A  FUTURE  WEAPON  DELIVERY  SYSTEM 


As  shown  in  Fig.  4  and  5  future  WDSs  will  be  strongly  influenced  by  the  general 
technology  progress.  Fig.  7  summarizes  some  aspects  of  progress  in  this  area. 
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Fig.  7:  Aspects  in  Weapons's  Control  equipment  progress 


5 . 1  Intelligence  Distribution 


Already  in  the  planning  phase  of  a  new  weapon  system  a  decision  has  to  be  taken 
whether  to  put  more  intelligence  into  the  weapon  carrier  (aircraft)  or  in  the  weapons 
themselves.  There  is  a  tendency  to  put  more  intelligence  into  the  weapons  but  obviously  there 
is  an  optimum  between  carrier  and  weapon  intelligence  considering  mission  success,  finan¬ 
cial  effort  and  vulnerability  risk.  Without  having  an  highly  intelligent  carrier,  the 
target  area  will  only  be  reached  with  higher  risk  and  the  information  given  to  the  mis¬ 
siles  will  not  be  sufficiently  accurate.  On  the  other  hand  a  very  intelligent  weapon  is 
necessary  to  increase  the  stand-off  range  (reduced  risk)  and  the  hit  probability. 


Intelligence 


Several  facts  should  be  considered  in  context  with  above  graph: 


The  higher  the  weapons  intelligence,  the  less  the  carrier's  intelligence 
required. 

The  higher  the  risk  for  the  aircraft,  the  more  capabilities  (range,  intel¬ 
ligence)  are  required  from  the  weapon. 

With  increasing  aircraft  intelligence  the  necessary  weapons  intelligence 
is  lower  (for  comparable  mission  success)  but  to  minimize  the  risk  it  should 
be  as  high  as  possible. 


6.  CONCLUSIONS 

The  principal  layout  of  a  fighter  aircraft  WDS  (Fig.  2)  does  not  change  very  much 
when  using  future  technologies.  The  great  changes  are  in  the  details.  The  cockpit  con¬ 
trols  are  concentrated  to  form  a  Multifunction  Keyboard,  Main  Computer  and  Missile  Com¬ 
puter  are  free  programmable,  the  Avionic  Interface  with  its  sensors  (i.  e.  Radar)  provides 
an  extended  range  for  target  acquisition.  The  weapons  themselves  have  more  and  more  intel 
ligence,  a  longer  range,  quicker  reaction  times,  are  less  sensitive  against  external  ECM 
and  can  directly  be  adapted  via  a  standardized  mechanic  and  electric  interface  inclu¬ 
ding  a  MIL-Bus  1553  B.  Because  of  the  concentration  of  control  elements  and  the  higher 
intelligence, the  workload  on  th  crew  is  getting  smaller  enabling  single  seater  aircraft 
without  loosing  combat  effeciency. 

Laser  weapons,  although  already  in  development  in  greater  aircraft  and  spacecraft, 
are  not  considered  in  this  paper,  because  with  the  existing  or  predicted  technologies 
they  can  not  be  used  in  fighter  aircraft  for  a  considerable  time  coming.  They  could  how¬ 
ever  strongly  influence  the  overall  situation,  especially  when  great  effective  space-based 
Laser  battle  stations  would  be  available  to  be  used  against  all  kinds  of  missiles  and 
aircraft . 
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Summary 


/ 

•The  ever  increasing  cost  of  test  software,  both  in  real  terms  and  in  relation  to  target 
software  cost,  is  posing  a  severe  burden  on  the  development  of  embedded  systems.  The 
comparative,  short  life  span  of  an  avionics  package  in  comparison  to  that  of  the  air¬ 
frame  further  emphasises  the  need  for  a  cost  effective  test  tool.  ~TU,  iS 


JTh<?  paper  outlines  the  development  of  CADAS/ -j.  a  computer  aided  design  tool  for  avionic 
systems.  Prior -to  outlining  the  basic  'ggnccpCs  behind -CABAS,  an  overview  of  present 
methods  for  validating  software  is  presented^  ■  ~*Tiiy  ' _ -^>  laaz/c  (U>rtCJjJ~rs  b<?l 

These  concepts ‘^are^  then  expanded  to  illustrate  how  certain  key  elements,  such  as  the  e- 
vents  language,  the  automatic  generation  and  inclusion  of  models^etc.  have  been  imple¬ 
mented. 


In  conclusion  the  paper  reports  on  the  usage  and  achievements  tokate  and  outlines  fch^ob- 
jectives  still  to  be  achieved.  Finally  the  case  for  including  stfch  a  general  tool  as  a 
basic  component  of  the  programming  support  environment  for  embedded  software  is  presented,  /f- 


1.0  An  Overview  of  CADAS 


1.1  Primary  design  aim 

Over  the  past  decade,  test  support  software,  whilst  usually  constituting  a  "by  product"  of 
an  avionic  development  program  has  generally  accounted  for  an  increasing  "bleed  off"  of 
available  project  funds.  This  development  when  combined  with  the  rising  cost  of  identify¬ 
ing  a  software  system  design  error  or  worse  still  a  program  error  at  final  hardware- 
software  integration  or  even  during  flight  trials,  has  resulted  in  many  projects  experi¬ 
encing  a  cost  explosion. 


Figure  1  Companion  batwaan  tha  growth  of  Tornado  OFF  toftwara  and  tha  raquirad  tast  software 


The  prime  aim  therefore  of  CADAS  was  to  provide  a  cost  effective  closed  loop  dynamic 
evaluation/development  tool  which  could  be  used  at  the  earliest  possible  stage  in  the  de¬ 
velopment  stage  of  the  system  life  cycle.  Since  CADAS  may  be  used  by  all  component  manu¬ 
facturers,  reliable  read  across  of  tests  may  be  achieved.  This  will  help  reduce  integra¬ 
tion  problems  and  permit  the  final  integration  rig  to  concentrate  more  on  the  assessment 
of  the  overall  system  performance. 

1 .2  Primary  design  features 

Of  all  the  required  features  minimal  maintenance  and  a  user  friendly  interface  were  con¬ 
sidered  to  be  of  prime  importance.  The  former  was  achieved  by  high  modularity  and  the 
implementation  of  the  software  in  a  high  order  language  (HOL) .  The  implementation  of  the 
system  as  a  multi-task  not  only  served  to  emphasize  the  former  but  easily  permits  the 

ji j  i"i  3  ?"i’i 

The  software  has  primarily  been  written  in  Fortran  (90%).  The  remaining  10%  being  written 
in  assembler,  due  to  hardware  interface  restrictions  such  as  A/D  converters,  real  time 
keyboard  and  D/A  converters. 

In  order  to  minimise  user  input  errors,  the  user  interface  is  primarily  via  menus.  Where 
text  input  is  required,  it:  nas  oeen  optimized  to  improve  rauit  tolerance,  questions  wmcn 
have  become  redundant  due  to  previous  answers  are  not  presented  to  the  user.  He  is  always 
prompted  for  data  in  a  positive  format,  that  is  the  nature  of  the  awaited  reply  is  de¬ 
ll  r*  <5.  lr  l(r  *aiw,  rttia  ubgc  will  bs>  i nf ocrt**!  a  "T”  at  e  "■»"  it 

however  where  character  strings  must  be  defined,  for  example  in  the  case  of  present  posi¬ 
tion,  the  user  is  presented  with  a  mask  to  aid  him  in  the  formatting  of  the  input.  However 
should  the  user  give  an  invalid  reply,  or  respond  with  a  question  mark,  he  is  presented 
with  tiis  appropriate  t_xt  ir tT.e  usurr  .u&iiual. 

In  order  to  support  test  activities,  the  system  is  built  around  a  data  base.  A  key  fea¬ 
ture  of  the  data  base  management  system  is  the  capability  given  to  the  user  to  define 
which  models  or  actual  hardware  units  he  wishes  to  activate  for  a  given  test.  However 

dTlwUld  c  iitodwi  not  Ob  u^dilullv.  flOm  the  HiflcLlACSS  Wj.li.il.  X.l,b  tiu ua  lldSb,  it  muy  i>b  dull 

matically  generated  and  inserted. 

As  a  final  design  consideration  it  was  predefined  that  the  system  should  run  on  commercial 
OEM  available  hardware. 

1.3  Computer  aided  design  tool  versus  test  tool 

A  good  software  development  and  maintenance  philosophy  stresses  the  need  for  demonstrat¬ 
ing  the  compliance  of  the  product  with  the  specification  at  each  stage  of  its  life-cycle. 
It  is  therefore  highly  desirable  to  be  able  to  apply  the  same  tool  in  all  phases  of  the 
software  life  cycle  (1).  Unfortunately,  most  software  tools  have  centered  around  the  de¬ 
tail  design  and  validation  phases.  The  tools  available  have  tended  to  reflect  that  they 
were  written  for  a  particular  end  user  and  as  such  provide  very  little  on-line  help. 

They  therefore  can  not  be  justifiably  defined  as  a  CAD. 

An  ideal  tool  should  support  the  user  to  perform  the  following  activities,  independent 
of  which  project  is  under  investigation. 

-  generate  the  required  test  environments  from  the  system  requirements 

-  provide  instrumentation  of  the  target  software 

-  automatic  execution  and  validation  of  the  target  software 

-  evaluate  data  and  update  test  coverage  report 

-  localise  and  identify  errors  in  target  software 

-  ease  design  and  development  of  "exception  handlers" 

-  provide  trace  back  and  cataloguing  of  previous  tests. 

In  order  to  provide  these  facilities  with  adequate  on-line  help,  the  tool  needs  to  be 
conceived  as  a  CAD  tool  as  opposed  to  just  a  test  tool. 

2.0  Present  simulation  and  test  tools 


2.1  Nature  of  present  test  systems 

Test  systems  may  be  subdivided  into  two  categories  based  upon  the  environment  generating 
processor (s) ,  that  is: 

i)  systems  which  are  supported  by  specialised,  and  therefore  expensive,  non  OEM  hard¬ 
ware,  for  example  specific  test  rigs  make  use  of  extensive  dual  ported  memory  and 
hardwire  features 

ii)  standard  OEM  processors  tailored  to  the  test  tool  role  by  means  of  their  software. 

The  former  will  not  be  considered  here,  as  its  cost  is  prohibitive  for  general  use  and 
its  disadvantages  are  well  known. 

Most  test  tools  of  the  second  category  originated  from  the  desire  to  posess  a  good  data 
acquisition  capability.  The  various  signals  from  the  avionic  equipments  were  to  be  gen¬ 
erated  by  providing  a  means  of  stimulating  the  actual  equipment.  The  rig  therefore  by 
definition  was  not  only  project  specific,  it  was  also  version  specific.  Unfortunately 
the  response  from  some  of  the  stimulated  equipments  such  as  the  inertia  navigation  plat¬ 
form  were  too  slow  to  be  of  any  use.  A  possible  solution  was  not  to  stimulate  the  IN  but 
to  mount  it  on  a  six  degrees  of  freedom  turn  table  and  generate  signals  to  drive  the 
turn  table.  However,  the  provision  of  the  latter  is  not  cost  effective  in  implementation 
except  for  the  final  system  integration  rig.  In  general  the  stimulation  of  equipments  in 


order  to  provide  a  realistic  environment  for  the  development  of  the  avionics  software 
may  be  summarised  as  follows:- 


r  € 


1 .  not  satisfactory  as  some  equipments  were  unable  to  respond  satisfactory 

2.  too  costly  and  version  specific 

3.  unable  to  generate  controlled  errors 

4.  unable  to  analyse  equipment  signals  on  line  in  a  suitable  manner  for  the  software 
systems  engineer 

5.  problematic  from  a  logistic  point  of  view, 
configuration  maintenance  problems. 


6. 


It  became  clear  that  for  software  development,  a  better  and  in  some  cases  the  only 
solution  was  to  simulate  the  appropriate  equipments  as  opposed  to  stimulating  them. 
Unfortunately  the  test  tools  had  been  developed  only  with  the  data  acquisition  require¬ 
ment  in  mind.  Partly  due  to  hardware  and  software  limitations,  the  models  which  were  to 
run  in  real  time  were  often  programmed  in  assembler. 


2.2  Simulation  techniques 


Whilst  the  time  slice  per  cycle  and  the  available  memory  to  a  large  extent  dictated  the 
level  of  complexity  or  simplicity  of  a  model,  the  difficulty  of  defining  models  in  as¬ 
sembler  served  only  to  simplify  them  further. 


The  advent  of  faster  processors  and  cheaper  memories  combined  with  the  development  of 
compilers  optimised  from  a  run  time  code  point  of  view  has  enabled  real  time  models  to 
be  written  in  HOLS. 


The  inherent  restrictions  and  difficulties  of  using  assembler  language  for  simulation 
purposes  have  long  been  recognised.  Many  programmers  indeed  would  even  argue  that  common¬ 
ly  used  HOLS  are  not  suitable  either  for  such  purposes,  and  as  a  result  such  languages 
as  SIMULA  and  DSL77  have  been  developed.  Whilst  the  latter  provide  a  very  friendly  inter¬ 
face  to  the  user  for  describing  complex  simulations,  the  resulting  models  may  be  very 
complex  and  may  only  run  in  simulation  as  opposed  to  real  time. 


The  depth  to  which  a  piece  of  equipment  is  simulated  will  reflect  the  extent  of  software 
and  hence  cycle  time  required.  Fortunately  in  order  to  validate  or  test  a  software  pack¬ 
age  only  a  subset  of  the  total  functions  of  a  given  equipment  are  normally  required. 
Therefore  the  performance  envelope  of  the  equipment  may  be  covered  by  a  summation  of  the 
individual  performance  envelopes  of  the  various  models.  This  concept,  of  course,  is  not 
new,  however  in  general  no  relational  control  between  the  various  versions  had  been  em¬ 
bedded  in  control  software,  but  relied  upon  the  user,  at  worst,  to  bury  the  appropriate 
models  in  code,  compile  and  task  build  prior  to  test  run.  This  procedure  from  the  QA 
point  of  view  of  course  was  unsatisfactory  since  the  test  tool  after  change  was  in¬ 
validated.  CADAS  has  provided  this  means  of  relational  control  between  the  various  models. 


2,3  Event  languages 


An  event  may  be  defined  as  the  change  of  state  of  at  least  one  signal  within  the  input/ 
output  area  of  the  test  tool.  This  signal  may  either  be  a  test  control  parameter  of  the 
test  system  for  example  to  switch  on  recording,  or  may  constitute  an  input  to  the  target 
software.  A  formal  means  of  predefining  these  changes  in  relation  to  test  time  is  prr*iu- 
ed  via  an  event  language. 


These  event  definitions  may  be  invoked  to  achieve  either  or  all  of  the  following  results:- 


i)  to  generate  an  automatic  repeatable  test 

ii)  to  provide  a  means  of  dynamically  switching  values  either  at  a  frequency  or  at  a 
given  time  that  would  be  difficult  to  achieve  via  a  human  input. 

iii)  Where  the  change  of  certain  variables  does  not  warrant  the  production  of  a  model 


Present  event  languages  may  be  classified  as  one  of  the  following 


1 .  Open  loop  and  too  simple  an  instruction  set  eg  ATESP 

2.  Oriented  towards  computer  scientists  as  opposed  to  software  engineers  eg  SOFTEST 

3.  Hardware  orientated  and  difficult  to  apply  to  task  of  testing  embedded  software  eg 
ATLAS. 


In  order  to  ease  the  user  interface  an  'ADA  like1  events  language  is  under  development 
for  CADAS.  This  is  an  attempt  to  provide  a  sophisticated  event  language  providing  such 
features  as  looping,  on  line  calculated  comparisons  etc,  which  will  have  the  same  grammar 
and  syntax  as  the  language  that  the  user  will  probably  be  programming  his  software  in.  The 
resultant  test  file  should  be  more  readable  and  comprehensible  to  such  authorities  as  QA 
and  project  management  than  previous  event  languages. 


2.4  Developments  in  software  validation  techniques 

There  are  at  present,  three  popular  methods  available  to  the  software  engineer  by  which 
he  may  establish  if  the  requirements  are  met: 


1)  program  testing  (2) 

2)  program  proving  (3) 

3)  symbolic  execution  (4) 


Program  proving  and  symbolic  execution  techniques  require  that  the  intended  behaviour  of 
the  target  software  be  defined  using  a  set  of  assertions,  which  in  turn  are  used  to  prove 
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mathematical  theorems  about  the  target  program.  Unfortunately  proof  techniques  tend  to 
be  'effort  intensive'  and  do  not  lend  themselves  easily  to  proving  parallel  programs. 
The  latter,  is  of  course,  a  characteristic  of  embedded  avionic  software. 
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ately,  in  order  to  prove  a  software  module  to  be  correct  an  inordinate  amount  of  testing 
is  required.  Since  input  domains  are  frequently  large,  test  data  sets  may  only  address 
a  subset  of  the  input  values  and  are  usually  only  used  in  "open  loop”  testing.  The  auto¬ 
matic  generation  of  test  data  is  the  aim  of  many  test  systems  under  development. 

Current  research  test  systems  such  as  RXVP  (5),  SADAT  (6),  FACES  (7),  DAVE  (8)  and  SQLAB 
(9)  emphasise  the  importance  of  measuring  test  coverage  at  the  expense  of  validating  the 
test  results.  In  general  they  generate  test  data  via  a  control  flow  analysis  of  the  target 
software,  ie  branch  and  path  testing  as  opposed  to  an  analysis  of  the  data  inputs  and 
outputs,  i.e.  cause  and  effect  testing  (10)  (11).  As  a  result  the  nett  effect  is  that  the 
program  is  tested  against  itself  by  deriving  the  test  cases  from  a  static  analysis  of  the 
program  structure  and  the  test  coverage  is  measured  via  a  dynamic  analysis  of  the  test 
paths  (1).  This  although  a  useful  tool  during  program  development  can  not  be  considered  as 
a  system  validation  aid. 

Satisfactory  software  validation  can  only  he  achieved  if  the  required  test  data  sets  are 
generated  from  the  requirements.  CADAS  does  not  set  out  to  define  groups  of  data  sets 
but  attempts  to  embody  the  requirements  in  a  set  of  models.  These  models  will  then  gene¬ 
rate  the  appropriate  test  data  in  real  time  to  correspond  to  the  present  situation  in  the 
performance  envelopes  of  the  respective  models. 

3.0  CADAS  General  concepts  and  philosophy 

3.1  Definition  of  test  environment 

The  effect  of  defining  groups  of  test  data  sets  or  of  activating  particular  models  is  to 
define  the  required  environment  in  which  the  target  software  is  to  be  tested. 

However  in  general  the  operational  envelope  of  a  given  target  system  is  too  large  to  be 
efficiently  defined  by  a  single  test  environment.  CADAS  permits  the  user  to  easily  de¬ 
fine  a  set  of  test  environments,  the  sum  of  these  will  define  the  maximum  possible  scope 
of  the  test  coverage.  These  test  environments,  as  opposed  to  data  sets  are  not  point  de¬ 
finitions,  but  define  a  subset  of  the  total  environment  envelope.  The  definition  of  this 
environment  is  known  as  the  preparation  mode. 

The  user  having  defined  his  environment,  then  goes  on  to  define  the  test  start  conditions 
via  the  initialisation  mode.  Having  satisfactorly  completed  this  action,  the  user  may 
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one  to  another  during  a  test. 

3.2  Application  Scenario 

Due  to  contractual  problems,  project  size  components  for  embedded  systems  tend  to  be 
developed  in  parallel  and  at  different  centres.  The  absence  of  a  common  test  system 
aoxjss  th=  field  of  ajtlvlty  Co...pll-atos  tl.t.  problems  assuoiattd  with  integration.  It  is 
therefore  intended  that  CADAS  should  be  capable  of  providing  a  unified  environment  at 
all  the  centres  of  development  and  should  be  usable  by  all  personnel  irrespective  of 
their  academic  discipline,  or  project  responsibility. 

Hit ref art  the  cryptic  type  of  test  data  definition  by  means  of  assertions  has  been  avoid 

ed. 


3.3  Use  of  CADAS  at  system  requirement  level 

In  recent  years  much  attention  has  been  given  to  the  development  of  requirement  and  speci¬ 
fication  languages.  With  the  aid  of  such  tools  it  is  possible  to  formally  define  specifi¬ 
cations  and  check  for  omissions  and  conflicts.  Ho«evex ,  they  do  not  prove  that  the  design 
requirements  are  realistically  achieved  and  in  a  cost  effective  manner.  Simulation  tech¬ 
niques  are  being  used  to  establish  product  feasibility.  However  the  software  models  devel¬ 
oped  Icc  this  phaw  are  net  aLway*  earned  yttut  to  other  Ibis  fyrte  pbaawi .  rtCM 
will  provide  the  capability  to  generate  models  from  the  requirements  via  an  interactive 
procedure.  These  models  in  turn  will  represent  the  test  data  by  which  the  software  may  be 
tested.  By  this  mechanism  CADAS  meets  the  need  to  generate  "testdata  independent  of  the 
program  specification"  (1) 

As  a  project  advances  the  specifications  of  the  equipments  can  be  updated  and  new  model 
versions  generated. 

4.0  CADAS  IN  MORE  DETAIL 

4 . 1  General  Structure 

CADAS  has  been  designed  as  a  multi  task/multi  processor/multi  user  system.  User  inputs 
have  been  minimised,  however  where  large  character  string  inputs  are  unavoidable,  for  in¬ 
stance  in  the  case  of  the  event  language,  use  has  been  made  of  screen  format  masks. 

Particular  activities  such  as  test  preparation  are  defined  as  modes.  Each  mode  is  composed 
of  at  least  one  task  but  may  be  more  (e.g  the  real  time  run  mode  is  at  least  7  tasks). 

Upon  entering  the  test  system,  the  user  is  first  requested  to  define,  via  a  menu,  which 
software  system  he  wishes  to  test.  This  enables  the  appropriate  data  to  be  retrieved 
from  the  data  base.  Control  is  then  passed  to  the  moding  executive. 
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Figure  2  System,  en virement  and  data  selection 


Control  from  one  mode  to  another  is  always  via  the  moding  executive  with  the  exception  of 
the  runtime  mode,  whilst  data  exchange  from  one  mode  to  another  is  via  the  data  base. 

The  termination  of  an  activity  in  a  given  mode  results  in  the  user  being  passed  automat¬ 
ically  back  to  the  moding  executive.  The  user  then  defines  his  next  activity  or  desire 
to  exit  via  the  moding  executive  menu.  The  user  can  only  enter  the  real  time  run  mode  via 
the  initialisation  mode.  This  exception  is  felt  necessary  in  order  to  guarantee  that  all 
the  required  data  and  hardware  units  have  been  correctly  initialised.  In  all  modes,  ex¬ 
cept  the  real  time  run  the  system  is  in  multi  user  mode. 
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Figure  3  Data  and  control  flow  on  CADAS 


When  in  the  initialisation  mode  is  reached,  i.e.  just  prior  to  entering  the  real  time 
run,  the  required  facilities  become  reserved  and  the  appropriate  components  of  the  multi 
processor  system  revert  to  single  user  capability.  Of  course,  if  the  system  is  running  on 
a  single  processor  configuration,  than  all  other  users  are  logged  out  of  the  system  in  a 
orderly  manner.  This  avoids  having  under  utilised  hardware. 

4 . 2  Test  Preparation  Mode 

Its  purpose  is  solely  to  define  the  required  test  environment,  by  means  of  the  following 
five  features: 

a)  a  unique  test  name 

b)  model  selections 

c)  'on-line'  display  selections 

d)  automatic  events  selection 

e)  recording  requirements  e.g.  definition  of  switches  etc. 

The  simulation  axis  may  be  further  divided  into  the  following  elements 

i)  environmental,  e.g.  weather,  terrain 

ii)  instrumentation,  e.g.  positional  sensors,  command  sensors 

iii)  target  software,  e.g.  simulation  modules  of  program  requirements 

iv)  platform,  e.g.  aircraft  (type  and  version) 

v)  platform  control,  e.g.  joystick 

vi)  facility  control,  e.g.  SMS 

vii)  associate  equipment,  e.g.  weapons 

viii)  point  of  interest,  e.g.  targets 

During  the  preparation  mode  interlocks  are  provided  in  order  to  ensure  that  no  incompat¬ 
ible  models  are  selected  or  that  no  redundant  questions  are  presented  to  the  user. 


Host  tests  will  not  require  very  detailed  models  for  all  equipments,  but  will  require 
an  emphasis  to  be  placed  only  on  a  subset.  For  example,  in  order  to  test  a  weapon 

delivery  package,  detailed  models  of  Laser  and  GMR  will  be  required  (whilst  naviga¬ 

tional  equipment  models  such  as  SAHR,  radar  altimeter  may  be  relatively  primative) . 

The  preparation  mode  allows  such  a  model  mix  to  be  defined,  thereby  permitting  the 
test  system  to  be  tuned  so  that  the  desired  specific  attribute  may  be  highlighted. 

The  end  product  of  the  preparation  mode  is  a  catalogued  file  which  contains  the  defin¬ 
ed  parameters  for  the  test.  The  task  of  preparing  tests  is  totally  independent  of  all 

other  modes  and  as  a  result  the  user  may  define  as  many  preparations  as  he  wishes  at 

one  or  more  sittings. 

4.3  Events  Editor  and  Language 

An  event  is  defined  as  the  change  of  state  of  at  least  one  signal  within  the  global  data 
area  of  CADAS.  This  signal  may  be  part  of  the  test  data  or  may  be  a  CADAS  control  vari¬ 
able,  such  as  freeze  test  activity. 

A  closed  loop  'ADA  looking'  events  langugage  is  under  development.  In  order  to  support 
this  feature  a  user  friendly  editor,  which  allows  the  user  to  create  his  files  in  a 
simple  and  controlled  manner,  (each  event  is  syntax  checked  on  line)  has  been  developed. 

It  has  been  established  that  the  syntax  and  grammar  of  ADA  are  more  than  adequate  to  de¬ 
fine  typically  required  events. 

With  FLTPRO  use  MISSION  1 

reset  CLOCK; 

press  PLN  on  TV/TAB_2; 

after  2  SECS 

press  NAV  on  TV/TAB_1 ; 

after  2  SECS 

press  KEY_3  on  TV/TAB_1; 
press  MAIN  on  NMCP; 
press  AUTO  on  NMCP; 
engage  BHH_MODE  on  AUTOPILOT; 

if  WAYPOINT_A  is  OVERFLOWN  then 
goto  LABEL; 

end if ; 

after  2  SECS 

press  IN  on  NMCP; 
disengage  AUTOPILOT; 
perform  A  HIGH  LOFT; 

EVENTS  inhibit; 

«  LABEL  »  after  1  SECS 

while  RANGE  from  AIRCRAFT-POSITION  to  WAYPOINT_B>  20  NM  then  loop 
null; 


end  loop; 

Start  RECORDING; 


Fig.  4  Example  of  CADAS  Event  Language 

The  philosophy  behind  the  implementation  of  the  language  has  been  similar  to  those  of 
SNOBOL  4.  That  is  the  initial  commands  are  translated  into  a  set  of  macro  assembly  in¬ 
structions,  which  in  turn  are  then  compiled  to  produce  object  code. 

The  translation  is  a  two  phase  process,  the  first  phase  translates  the  lexical  text  into 
a  series  of  dictionary  entry  codes.  Upon  definition  by  the  user  on  which  machine  the 
events  will  run  during  the  test,  the  appropriate  sections  of  the  events  dictionary  are 
accessed  to  create  the  required  macro  instructions.  After  compilation  the  task  builder/ 
linker  instructions  are  removed. 

During  the  real  time  execution  the  events  are  read  into  a  reserved  buffer  in  memory, 
entry  to  which  is  controlled  by  a  server  routine. 

A  typical  area  of  application  for  such  a  feature  in  the  future  would  be  for  the  design 
and  validation  of  "exception  handlers". 

The  concept  of  exception  handlers  has  been  received  with  mixed  feelings:- 

"and  some  of  them,  like  exception  handling,  even  dangerous.  We  relive  the  history  of  the 
motor  car.  Gadgets  and  glitter  prevail  over  fundamental  concerns  of  safety  and  economy" 
(12). 

"It  is  clear  that  the  use  of  an  exception  provides  the  better  structured  program"  (13). 

"ADA  is  designed  to  permit  defensive  or  fault-tolerant  programming.  This  is  in  contrast 
with  traditional  styles  of  programming,  in  which  there  is  an  implicit  assumption  that 
everything  is  correct"  (14). 
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An  analogy  may  be  drawn  between  the  acknowledgement  that  embedded  systems  may  not  be  re¬ 
liably  declared  as  perfect  and  the  development  of  Fracture  mechanics  in  the  50’ s.  With¬ 
out  the  development  of  the  latter,  the  use  of  light  alloys  in  safety  critical  areas 
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would  be  severely  limited. 

"Exceptions  should  be  used  for  rarely  occurring  cases  or  those  which  are  inconvenient  to 
test  for  at  their  point  of  occurrence"  (10).  They  should  certainly  not  be  used  in  the 
form  of  a  generalised  'catch  all'  mechanism,  but  rather  for  the  systematic  step  by  step 
identification,  evaluation  and  subsequent  removal  of  "grey  areas"  during  system  develop¬ 
ment  as  well  as  their  containment  in  service.  The  nett  effect  of  this  should  be  to  lead 
to  a  better  fault  tolerant  system. 

With  the  help  of  CADAS  it  should  be  just  as  easy  to  exercise  and  validate  exception  hand- 
leic  ac  it  it.  ti.  than..  Ly  d  Ui.  iasiyn-i  to  i&i ini  thu  details  his 

required  handlers  externally,  that  is  via  the  event  language,  time  to  develop  and  valid¬ 
ate  will  be  minimised.  Configuration  control  improved  and  interface  problems  with  other 
designers/programmers  will  be  reduced. 

Once  the  details  are  frozen,  the  fact  that  the  lexical  construction  is  already  ADA  com¬ 
patible,  will  permit  its  automatic  migration  into  the  target  system. 

4.4  Initialisation  and  Realtime  Run 

This  mode  allows  the  user  to  predefine  his  initial  start  point  in  the  predefined  environ¬ 
ment.  Interlocks  are  provided  between  this  mode  and  that  of  preparation  to  ensure  that 
the  user  may  only  initialise  the  relevant  variables.  Prior  to  the  real  time  run,  an  ac¬ 
tive  timing  check  is  made  to  establish  the  cycle  load  of  the  simulation.  During  the  real 
time  run  the  user  may  activate/suspend  activities,  such  as  events  or  recording.  He  is 
further  provided  with  an  on-line  display  of  variables,  the  units  of  which  may  be  changed 
at  any  time,  input/output  channels  may  be  disabled/enabled  from  the  display  monitor  and 
the  test  itself  may  be  frozen  to  allow  the  user  to  examine  any  element  of  his  data  area. 

The  capability  for  'on-line'  analysis  is  an  important  aid  in  reducing  the  data  satura¬ 
tion  which  normally  accompanies  a  test  run.  For  many  tests  it  is  sufficient  just  to  be 
able  to  demonstrate  that  certain  discretes  are  generated  or  particular  bit  patterns  set. 
The  'on-line'  monitor  permits  this  to  be  achieved  without  the  penalty  of  having  to  per¬ 
form  an  inordinate  amount  of  post  test  data  reduction. 

After  completion  or  termination  of  the  test  whilst  in  the  initialisation  and  rear  time 
mode  the  user  may  opt  to  reinitialise  the  same  environment,  or  to  leave  the  mode  and  for¬ 
mally  reenter.  The  latter  enables  him  to  define  another  environment. 

The  ability  to  reinitialise  the  same  environment  within  the  initialisation  mode  has  a 
dramatic  effect  on  the  rig  usage  efficiency  of  the  system.  All  the  real  time  tables  and 
hardware  initialisation  requirements  are  still  valid  and  therefore  the  user  needs  only 
tc  J  tint  tu>  initial  aircTS.lt  attitude  positional  lata.  9h±s  nas  tn.  iratt  _li_ct  tnat  a 
turn  round  time  between  tests  is  reduced  by  a  factor  of  four  to  five. 

On  completion  of  the  real  time  run  the  user  is  supplied  with  a  report  detailing  which 
test  conditions/assertions  were  not  met,  and  the  recorded  observations  of  the  defined 
software  instrumentation. 

4 . 5  Replay  and  Analysis 

Having  defined  which  test  results  he  wishes  to  analyse,  the  user  is  provided  with  a 
test  report  in  graphic  and  written  form.  The  recorded  data  may  be  replayed  at  varying 
speeds.  Using  the  software  requirement  models,  the  recorded  data  may  be  used  to  recon¬ 
stitute  internal  signals  in  order  to  help  fault  identification.  The  user  also  has  the 
possibility  of  using  the  test  data  to  generate  an  events  file,  thereby  enabling  a 
manual  test  to  be  repeated. 

4.6  Housekeeping  Mode 

This  mode  provides  the  user  with  the  capability  to  perform  such  actions  as:- 

1)  Test  case  and  result  traceback 

2)  Update  of  data  base 

3)  Automatic  insertion  of  new  model 

4)  Amend  appropriate  dictionaries 

The  most  important  feature  of  the  four  is  the  ability  to  generate  and  insert  new  models 
automatically.  The  model  is  initially  defined  using  the  specification  language  EPOS. 

Using  the  decomposition  feature  it  is  possible  to  define  in  detail  the  required  algo¬ 
rithms  and  the  parameter  names  to  be  used.  Once  it  has  been  established  that  the  speci¬ 
fication  contains  no  conflicts  or  omissions,  the  data  file  will  be  accessed  and  the 
contents  translated  into  a  CADAS  compatible  model. 

At  present  such  a  transformation  is  only  possible  into  PEARL  programs.  It  has  been  de¬ 
monstrated  that  if  a  model  complies  wibh  a  predefined  structure,  it  may  be  automatically 
inserted  into  CADAS.  From  work  carried  out  todate,  it  would  appear  that  this  structure 
is  applicable  to  all  models. 

Following  QA  acceptance  the  model  would  then  be  inserted  into  the  appropriate  libraries 
automatically. 


5.0  Trends  in  CAPAS  development 


5.1  Realised  capabilities  of  CAPAS 

The  system  as  a  prototype  has  been  run  on  a  PDP  11/60  and  used  to  exercise  not  only  the 
operational  flight  program  but  also  the  Build  Test  Program  for  the  Tornado  IDS  aircraft. 
Open  and  closed  loop  tests  have  been  carried  out  manually  and  automatically.  Using  the 
ability  to  simulate  equipment  errors  with  an  undulating  simulated  terrain  have  enabled 
tests  to  be  carried  out  that  would  be  normally  impossible  with  actual  hardware  equipments 
and  would  require  extensive  flight  trials. 

A  worst  case  cycle  loading  of  83%  has  been  measured  in  trials,  however  this  was  with  a 
recording  frequency  of  only  10  Hertz.  A  recording  frequency  of  50  Hertz  is  at  least  re¬ 
quired.  Therefore  in  order  to  develop  CADAS  further,  the  already  designed  capability  of 
being  supported  by  multi  processors  must  be  implemented  and  realised. 

5.2  Apse's  and  all  that 

Whilst  the  accronym  APSE  is  an  ADA  specific  term,  the  engineering  fundamentals  which  it 
embodies  have  to  some  extent  long  been  recognised  as  essential  for  the  development  of  an 

embedded  system.  APSE  is  an  attempt  to  standardise  the  various  components  and  their  inter¬ 

action  with  one  another.  Certain  components  of  the  APSE  such  as  compilers,  command  lan¬ 
guage  interpreters  and  data  base  management  have  received  wide  attention  in  contrast  to 
design  aids  and  verification  tools.  "Stoneman"  acknowledges  that  "the  testing  phase  of  a 
project  is  often  more  expensive  than  development"  (15)  and  goes  on  further  to  say  that 

"in  the  past  and  in  much  of  current  practice,  the  concept  of  a  support  system  is  not  muc’. 

in  evidence.  The  tools  available  are  not  well  integrated,  nor  do  they  form  a  complete  set". 

Whilst  it  acknowledges  that  the  provision  of  an  environment  simulator  is  of  particular 
importance  and  that  it  may  well  require  as  much  effort  to  design  and  build  as  a  major 
component  of  the  system  under  development,  it  accepts  the  concept  that  environment  simu¬ 
lators  must  be  project  specific. 

Clearly  elements  of  the  environment  must  be  by  definition  project  specific,  however  only 
elements  need  be,  not  the  total  simulator.  An  ideal  general  environment  simulator,  must 
provide  the  capability  for  the  user  to  define  his  requirements,  inform  him  on  which  ele¬ 
ments  need  to  be  generated,  and  via  an  interactive  definition  mechanism,  define  and  gene¬ 
rate  the  missing  elements. 

The  need  for  such  a  facility  is  not  only  justified  within  the  context  of  multiple  pro¬ 
jects  but  also  within  the  life  cycle  of  an  individual  project.  "Stoneman"  clearly  de¬ 
fines  the  development  nature  of  a  software  project :- 

"The  envoi ving  nature  of  the  requirements,  where  an  initial  general  specification  is  made 
more  precise  as  the  project  proceeds.  This  produces  rapid  interactions  between  design  and 
experiment"  (15). 

In  order  to  allow  the  designer  to  rapid  prototype  and  evaluate  the  proposed  changes,  he 
must  have  a  flexible,  easily  reconfigured  simulation  environment.  The  extension  of  the 
mechanism  which  allows  this  flexibility  within  a  project  to  that  of  flexibility  between 
projects  is  a  logical  step. 

Whilst  such  a  tool  cannot  be  classified  as  an  APSE  basic  element  since  it  will  undoubt- 
ly  build  upon  the  data  base  and  the  command  language.  The  cost  and  complexity  would 
warrant  that  such  a  general  test  tool  be  included  in  the  MAPSE.  After  all  ADA  and  APSE’s 
have  been  specifically  developed  with  embedded  systems  in  mind,  and  testing/validation 
is  an  important  element  of  that  activity. 

CADAS  has  shown  that  it  is  possible  to  implement  a  test  tool,  which  may  not  only  be 

Uaallj  dill  duLUiudLiwdilj  but  la  IKdt  pXO  jtsut  a^mCiliO.  1,1  Jaial  ivj  Uuiupijr  idlij 

with  the  spirit  of  "Stoneman"  CADAS  will  need  to  be  redesigned  in  ADA,  but  only  as  a  long 
term  aim.  Stoneman  acknowledges  that  initially  elements  may  be  included  in  an  APSE  which 
are  not  written  in  ADA,  but  their  interface  should  at  least  conform  to  that  of  the  KAPSE. 
Unfortunately,  at  the  moment  these  interfaces  are  not  yet  defined. 

5.3  Limitations  and  developments  on  CADAS 

Whilst  CADAS  will  aid  and  speed  up  the  process  of  validating  software  systems,  it  must 
ft  i  1. 1  V  rH’Wmher?  J  tbal  te^ti’’^  "ly  show*!  ;  rpqsnrf*  but  not  thp>  ahpe"oe  of  soft¬ 

ware  errors.  In  the  maintenance  phase  of  large  systems,  it  will  always  be  necessary  to 
isolate,  identify  and  rectify  errors.  The  capability  to  use  a  test  tool  without  special¬ 
ist  knowledge,  as  is  the  case  with  CADAS,  will  play  an  important  part  in  the  success  or 
otherwise  of  such  tasks. 

Present  development  work  is  centered  around  the  following  areas :- 

1 .  Validating  multi  processor  capability 

2.  completing  the  implementation  of  the  ADA  like  event  language 

3.  improving  recording  and  replay  capabilities 

4.  validating  an  EPOS  interface  concept. 

5.4  Further  areas  of  application  for  CADAS 

Due  to  its  capability  to  provide  "hands  on11  real  time  simulation  of  a  system,  the  applica¬ 
tion  of  CADAS  is  not  just  restricted  to  that  of  validating  software  packages,  but  may 
also  be  used  to  provide  the  end  user  with  a  cost  effective  systems  trainer.  Particular¬ 
ly  in  the  avionics  application  it  could  be  used  as  a  crew  procedure  trainer. 
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At  the  other  end  of  the  system  life  cycle,  the  user  could  apply  it  to  perform  a  compari 
son  of  proposed  solutions  for  a  given  system,  for  example  to  graphic  presentation  of  in 
formation  in  a  cockpit. 
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ABSTRACT 

^o  achieve  electromagnetic  compatibility  (EMC)  among  the  electric,  electronic  and  elec¬ 
tromechanical  systems  in  a  complex  airborne  weapons  system,  the  coordination  of  many 
engineering  disciplines  is  required  from  concept  to  delivery.  Often  the  primary  objec¬ 
tives  of  structural,  mechanical  and  electrical  design  will  be  in  direct  conflict  with  good 
EMC  practices.  Interaction  of  the  EMC  organization  with  many  diverse  engineering  groups 
which  have  a  common  organizational  tie  only  at  a  high  level,  usually  the  Chief  Engineer, 
requires  a  flexible  management  structure  with  hard  line  reporting  within  the  EMC  organi¬ 
zation  and  soft  line  ties  to  the  supported  organizations. 


The  major  milestones  required  to  achieve  an  electromagnetically  compatible  system  are: 

Planning  for  EMC  control > 

•  Analysis  to  highlight  potential  problem  areas j 

•  Engineering  evaluation  tests  to  prove  design  concepts* 

!-»  Qualification  testing  of  subsystems/equipments^j 

V  Safety-of-Flight  testing  on  airplane  to  assure  flight  safety  ;  -<  >r 

0  System  level  EMC  testing  where  safety  margin  demonstrations  may  be  required 

This  paper  discusses  the  steps  required  to  accomplish  the  milestones  listed  above  and  to 
assure  that  the  weapon  system  will  have  a  high  probability  of  passing  the  final  system 
level  electromagnetic  compatibility  demonstration. 


INITIAL  PLANNING 


In  order  to  achieve  electromagnetic  compatibility  in  the  design  of  a  new  aircraft  or  a 
major  modification  to  an  existing  aircraft,  the  EMC  engineering  group  is  probably 
required  to  interface  with  more  engineering  organizations  than  any  other.  Although  the 
EMC  effort  is  small  compared  with  the  total  budget  of  a  large  program,  the  large  amount 
of  interdisciplinary  coordination  required  makes  it  mandatory  that  the  project  manager 
put  his  EMC  group  in  a  place  within  his  organization  *"o  give  it  maximum  access  to  all 
other  engineering  disciplines.  Major  programs  with  which  the  author  has  been  associated 
have  employed  organizational  structures  in  which  EMC  is  part  of  the  project  as  shown  in 
Figure  1  and  where  EMC  is  part  of  a  Technical  Staff  which  supports  several  engineering 
projects  as  shown  in  Figure  2. 


FIGURE  1 

PROJECT  ORIENTED  EMC  ORGANIZATION 
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FIGURE  2 

STAFF  ORIENTED  EMC  ORGANIZATION 

The  success  of  each  approach  is  dependent  upon  the  size  and  number  of  projet. cs  being 
conducted  simultaneously  and  to  some  extent  upon  the  personalities  of  the  individuals 
involved.  The  design  and  fabrication  of  a  new  military  aircraft  or  a  major  aircraft 
modification  would  have  a  budget  large  enough  to  support  an  EMC  group  within  the 
project's  organizational  structure.  This  approach  has  the  advantage  that  the  EMC  team 
is  dedicated  to  one  program  which  eases  the  problem  of  assigning  priorities  among  a 
number  of  programs.  On  the  other  hand,  if  large  numbers  of  technical  disciplines  sup¬ 
porting  the  program  are  assigned  to  a  central  technical  staff  unit,  coordination  with 
these  individuals  might  be  more  easily  accomplished  if  the  EMC  group  were  part  of  the 
central  technical  staff. 

In  any  event,  wherever  the  project  manager  decides  to  put  the  EMC  team,  he  should  make 
the  decision  as  early  as  possible  and  should  make  sure  that  the  EMC  group  begin  their 
interdisciplinary  coordination  soon.  The  amount  of  freedom  that  the  EMC  group  should  be 
given  to  perform  coordination  directly  with  other  engineering  groups  without  going 
through  formal  vertical  management  lines  will  depend  on  the  initiative  and  competence  of 
the  lead  EMC  engineer  and  the  amount  of  freedom  to  use  his  own  judgment  the  project 
manager  feels  comfortable  about  giving  him.  Ideally,  the  EMC  engineer  would  do  the 
majority  of  his  coordination  with  other  groups  through  horizontal  or  "soft  line"  channels 
and  use  formal  vertical  communications  channels  mainly  for  reporting  functions. 

PRELIMINARY  ANALYSIS 

EMC  requirements  are  traditionally  written  into  contracts  by  referencing  various  specifi¬ 
cations  which  prescribe  subsystem/ equipment  level  EMC  design  and  test  requirements  and 
other  specifications  which  prescribe  EMC  system  level  test  requirements.  Some  U.  S. 
Military  standards  and  their  NATO  Standardization  Agreement  complements  are  shown  in 
Table  I. 
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U.  S.  STANDARD 
MIL- STD-461 

Electromagnetic  Emission  and 
Susceptibility  Requirements  for 
the  Control  of  Electromagnetic 
Interference 

MIL- STD- 462 

Electromagnetic  Interference 
Characteristics,  Measurement  of 

MIL-E-6051 

Electromagnetic  Compatibility 
Requirements,  Systems 


NATO  STANDARD 
STANAG  3516 

Electromagnetic  Compatibility 
of  Aircraft  Electrical  and 
Electronic  Equipment 


STANAG  3416 

Electromagnetic  Compatibility 
of  Aircraft  Systems 


TABLE  I 

COMPARISON  OF  U.  S.  AND  NATO  EMC  STANDARDS 

Specifications  and  standards  are  written  to  cover  general  cases  and  cannot  possibly 
include  the  detailed  information  necessary  to  assure  achieving  electromagnetic  compati¬ 
bility  at  a  reasonable  cost  for  a  particular  design.  This  is  why  it  is  extremely  impor¬ 
tant  that  an  early  preliminary  analysis  be  performed  and  that  the  results  of  the  analysis 
be  compared  to  the  standards  and  specifications  referenced  in  the  contract.  Relatively 
large  sums  of  money  may  be  involved  if  requirements  are  left  in  the  contract  which  are 
not  actually  necessary  to  achieve  an  electromagnetically  compatible  system  and,  as  time 
passes,  it  is  usually  more  and  more  difficult  to  get  a  change  to  the  contract.  Therefore, 
any  change  to  contractual  requirements  should  be  defined  as  early  as  possible. 

The  manner  in  which  the  contractor  plans  to  meet  the  electromagnetic  compatibility 
requirements  is  contained  in  a  document  called  an  EMC  Control  Plan,  which  is  normally 
required  to  be  submitted  90  days  after  contract  award.  This  plan  will  contain  any 
tailoring  to  specification  limits  and  any  deviations  to  specified  test  procedures.  After 
approval  by  the  procuring  activity,  the  EMC  Control  Plan  becomes  a  contractual  document. 

If  any  tailoring  of  specification  limits  or  deviations  to  test  procedures  can  be  defined 
prior  to  publishing  the  EMC  Control  Plan,  they  should  be  incorporated  into  the  Statement 
of  Work  or  other  top  level  contractual  document  at  the  earliest  possible  time.  Since 
there  may  be  several  tiers  of  contractual  documents  from  a  top  level  Statement  of  Work 
down  through  specifications  placed  on  suppliers,  it  is  important  that  all  of  these  con¬ 
tractual  documents  contain  a  consistent  set  of  EMC  requirements. 

Some  parameters  which  may  have  significant  cost  and  schedule  impact  and  which  should  be 
considered  when  tailoring  specification  limits  and  test  procedures  are: 

•  Radio  Frequency  Field  Intensity  Environment 

•  Acceptable  Switching  Transient  Levels 

•  Electrical  Power  Quality 

•  Safety  Margin  Requirements 

PITFALLS  TO  AVOID 

Experience  on  a  number  of  programs  has  shown  that  some  potentially  disastrous  consequences 
can  be  avoided  by  taking  some  relatively  simple  precautions.  A  few  of  these  experiences 
are  listed  below: 

•  The  structures  design  groups  may  be  unaware  that  structural  design  affects  EMC 
and  may  not  think  to  route  the  structural  drawings  through  EMC  for  approval.  Metal 
aircraft  skin  provides  at  least  20  decibels  of  shielding  effectiveness.  If  the 
designer  decides  to  use  fiberglass  or  composite  materials  for  some  structural  parts 
and  there  are  sensitive  electronic  components  within  these  areas,  the  result  could 
be  radio  frequency  interference  which  could  be  expensive  to  correct. 

•  Designers  of  servo  systems  with  high  frequency  cutoff  of  a  few  hertz  may  not 
think  to  route  their  drawings  through  EMC  because  the  response  of  their  system  is 
well  below  the  frequency  of  any  interference  source  generated  on  the  airplane.  In 
reality,  operational  amplifiers  are  good  radio  frequency  detectors.  Any  modulation 
on  the  rectified  radio  frequency  signal  which  is  within  the  servo  system's  band¬ 
width  will  be  seen  by  the  system  as  a  desired  signal  and  it  will  pass  through  the 
system  to  the  servo  actuator  as  interference. 

The  above  are  just  two  examples  of  communications  breakdown  between  design  and  EMC  groups 
which  can  lead  to  catastrophic  consequences.  Designs  which  on  the  surface  appear  to  be 
unrelated  to  EMC  may  in  fact  be  profoundly  affected.  It  cannot  be  stressed  too  firmly 
that  the  project  manager  should  insist  that  the  EMC  engineer  become  familiar  with  the 
work  of  all  design  organizations,  whether  they  appear  to  be  related  to  EMC  or  not,  and 
assess  the  designs  for  potential  EMC  impact.  A  little  effort  here  early  in  the  program 
will  lessen  the  likelihood  of  problems  arising  later  on. 

HANDLING  CONFLICTING  REQUIREMENTS 

There  are  cases  where  the  best  EMC  design  practices  may  cause  undesirable  side  effects. 
Putting  overall  shields  on  cables  decreases  radio  frequency  coupling  and  thereby  reduces 
the  probability  of  interference  to  electronic  circuits  but  it  also  increases  cost  and 


weight  and  makes  them  stiffer  and  harder  to  install.  Adding  excessive  power  line  filters 
with  capacitance  to  ground  increases  interference  immunity  but  it  also  causes  leakage 
currents  to  flow  in  the  power  lines.  Certain  types  of  electronic  circuits  are  degraded 
by  capacitance  to  ground  whereas  adding  shielding  on  interconnecting  cables  to  protect 
them  from  external  radio  frequency  fields  adds  capacitance.  To  achieve  compatibility , 
structural  parts  may  be  required  to  be  electrically  bonded  whereas  passivating  techniques 
to  reduce  corrosion  may  insulate  the  parts. 

Conflicting  requirements  such  as  those  discussed  above  must  be  handled  on  an  individual 
basis,  ordinarily  with  some  compromise  to  both  EMC  and  system  performance.  The  project 
manager  should  encourage  compromises  to  be  worked  out  at  a  lower  level  with  the  goal  of 
achievin.  as  little  degradation  to  both  system  performance  and  EMC  as  possible.  If  this 
cannot  be  accomplished,  the  manager  may  have  to  mane  ttie  ulLlwate  decision  as  iu  vAmL 
compromises  are  accepted.  If  this  is  the  case,  the  manager  should  make  sure  that  all 
alternative  approaches  are  explained  to  him  to  aid  him  in  making  the  final  decision. 

PREPARATION  FOR  TEST 

Testing  to  verify  that  EMC  requirements  have  been  met  usually  consists  of  three  types  of 
tests.  The  first  is  conducted  at  the  subsystem  or  equipment  level  in  a  shield  room  to 
verify  compliance  with  component  level  requirements.  Next  the  equipment  is  installed  on 
the  airplane  and  a  safety-of-f light  test  is  conducted  on  the  ground  prior  to  first  flight 
to  assure  that  systems  required  for  flight  are  not  adversely  affected.  Finally,  when 
production  hardware  is  available,  a  system  level  test  is  conducted  on  the  airplane  where 
all  potential  sources  are  exercised  against  all  potential  receptors. 

Proper  planning  is  essential  if  reasonable  test  schedules  are  to  be  met.  Adequate  time 
should  be  allowed  to  prepare  test  procedures  and  to  design  and  construct  any  special 
instrumentation  required.  A  test  program  requiring  safety  margin  demonstration  at  the 
system  level  requires  that  approximately  18  months  be  allowed  from  program  go  ahead  to 
final  system  level  test. 

Test  procedures  for  the  shield  room  test  should  include  detailed  steps  for  operating  the 
equipment  under  test,  the  method  used  to  determine  if  interference  is  present  and  precise 
pass  fail  criteria.  The  procedures  should  clearly  state  any  tailoring  to  specification 
limits.  For  systems  that  are  computer  controlled,  it  is  likely  that  special  test  soft¬ 
ware  will  have  to  be  developed.  Adequate  time  should  be  given  to  the  software  design 
group  to  produce  the  program  and  they  should  be  given  detailed  test  requirements  so  they 
will  know  what  the  software  is  required  to  do.  Ordinarily  the  unit  under  test  is  housed 
in  one  shield  room  and  test  aids  used  to  exercise  the  equipment  are  housed  in  an  adjacent 
shield  room.  The  test  procedure  should  include  detailed  diagrams  showing  equipment 
locations  and  interconnecting  wiring. 

Safety-of-flight  test  procedures  should  contain  detailed  step-by-step  procedures  for 
operating  the  equipments  required  for  test  and  pass  fail  criteria  to  be  used  for  accepting 
oi  rtjfcCLJ-ug  team  results .  althougii  -net  texatti  ui.lcCi.ly  Co  irxsiit  f  Ri  -,  S.4  4*  fett- 
practice  to  monitor  flight  test  instrumentation  for  interference  to  assure  that  data 
taken  during  subsequent  test  flights  will  not  be  perturbed  by  interference. 

Planning  for  svstem  level  testing  requires  the  longest  lead  time  of  the  three  types  of 
EMC  tests.  MIL-E-6051  requires  safety  margin  demonstrations  of  6  decibels  for  electronic 
circuits  and  20  decibels  for  explosive  circuits  when  approved  by  the  procuring  activity 
where  EMC  problems  could  result  in  loss  of  life,  loss  of  vehicle,  mission  abort,  unaccept¬ 
able  reduction  in  system  effectiveness,  damage  to  vehicle  or  reduction  in  effectiveness 
that  would  endanger  mission  success.  If  safety  margin  demonstrations  are  required,  an 
analysis  must  first  be  accomplished  to  identify  the  circuits  that  fall  within  the  speci¬ 
fied  criteria.  These  will  be  determined  by  the  criticality  of  function  and  circuit 
susceptibility.  Thin  film  thermocouples  attached  to  electro-explosive  device  (EED) 
bridgewires  to  measure  heat  rise  have  been  successfully  used  for  measuring  safety  margins 
of  EEDs.  A  method  of  sensitizing  digital  circuits  to  demonstrate  the  required  safety 
margin  as  shown  in  Figure  3. 


FIGURE  3 

SENSITIZATION  NETWORK  FOR  SAFETY  MARGIN  DEMONSTRATION 
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The  diodes  change  the  bias  on  the  circuitry  so  that  switching  levels  become  more 
sensitive  than  normal.  Diodes  must  be  individually  selected  to  achieve  the  level  of 
sensitization  required.  A  typical  schedule  for  a  system  level  test  program  with  safety 
margin  demonstrations  is  shown  in  Figure  A. 
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FIGURE  A 

TYPICAL  SCHEDULE  FOR  SYSTEM  LEVEL  EMC  TEST 
WITH  SAFETY  MARGIN  DEMONSTRATION 

Instrumentation  used  for  safety  margin  demonstrations  should  be  calibrated  in  the 
laboratory  prior  to  installation  on  the  airplane  for  the  test. 

TESTING 

The  ease  with  which  testing  can  be  accomplished  will  be  determined  to  a  great  extent  by 
the  qualityof  the  test  procedures.  The  systems  under  test  will  be  new  and  the  operators 
will  have  limited  experience  in  operating  them  so  the  test  steps  should  be  complete  and 
unambiguous.  Remember,  it  is  much  easier  to  figure  out  how  a  system  should  be  operated 
when  sitting  at  a  desk  in  a  warm  office  than  it  is  when  standing  on  a  blustery  flight 
line. 

In  conclusion,  the  success  of  an  EMC  program  on  a  new  airplane  or  major  airplane  modifi¬ 
cation  is  largely  determined  by  the  planning  and  analysis  conducted  in  the  early  days  of 
the  program.  If  these  have  been  properly  executed,  the  testing  should  be  a  routine 
matter  to  confirm  that  the  requirements  have  been  met.  It  is  hoped  that  this  paper  will 
be  of  help  to  those  charged  with  planning  and  administering  EMC  programs. 
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DISCUSSION 


G.Hunt,  UK 

Is  the  type  of  avionic  system  described  by  Mr  England  in  Paper  No.  1 ,  which  utilizes  commonality  of  data  processing 
and  transmission  of  raw  sensor  data,  likely  to  provide  particular  EMC  difficulties? 

Author’s  Reply 

I  think  not,  especially  if  the  data  are  transmitted  digitally,  which  is  the  current  trend.  I  have  found  that  digital  data 
transmission,  if  handled  correctly  is  quite  immune  to  interference  effects.  We  have  had  some  experience  with  Flight 
Test  Instrumentation  Systems  which  handle  data  essentially  as  Mr  England  proposed,  which  proved  to  be 
interference  free. 


D  Jaeger,  Ge 

What  is  your  experience  in  using  EMC-computer  program  instead  of  practical  demonstrations  of  safety  margins?  For 
example,  if  you  have  calculated  a  safety  margin  of  about  50  dB  which  may  be  expected,  is  it  necessary  to 
demonstrate  >  6  dB  by  practical  measurements? 

Author’s  Reply 

No.  Our  computer  aided  analysis  program  has  proved  to  be  at  least  90%  accurate.  All  errors  so  far  have  been  in  the 
safe  direction.  The  analysis  program  has  predicted  some  interference  that  did  not  occur  but  I  have  not  seen  an 
interference  that  was  not  predicted. 
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•Arnes  Research  Center  initiated  a  program  in  1975  to  provide  the  critical  information  required  for  the 
design  of  integrated  avionics  suitable  for  general  aviation.  The  program  has  emphasized  the  use  of  data 
busing,  distributed  microprocessors,  shared  electronic  displays  and  data  entry  devices,  and  improved  func¬ 
tional  capability.  Design  considerations  have  included  cost,  reliability,  maintainability,  and  modularity. 
As  a  final  step,  a  demonstration  advanced  avionics  system  (DAAS)  was  designed,  built,  and  flight  tested  in 
a  Cessna  402,  twin-engine,  general-aviation  aircraft.  Ttre~purpose  oE^is  paper  <rt~to/>  provide^  functional 
description  of  the  DAAS,  including  a  description  of  the  system  architecture,  and  briefly  reviewjthe  pro¬ 
gram  and  flight-test  results. 


1.  INTRODUCTION 

During  the  1970s,  increasing  demands  were  made  of  the  general-aviation  pilot.  Operating  procedures 
were  becoming  more  complicated,  regulations  were  more  restrictive,  and  the  demands  of  the  National  Airspace 
System  were  increasing.  During  this  same  period,  the  general-aviation  avionics  industry  aggressively 
applied  new  technology  to  meet  these  requirements  at  affordable  prices.  However,  these  developments  were 
along  traditional  lines  with  integration  occurring  only  in  a  few  specific  areas,  such  as  navigation/ 
comnuni cation  systems  and  integrated  flight  director/autopilot  designs.  Using  this  approach  of  limited 
integration,  the  addition  of  more  sophisticated  capabilities,  such  as  a  performance  computer,  an  intelli¬ 
gent  monitoring  and  warning  system,  or  a  ground-proximity  warning  system,  becomes  expensive  and  cumbersome 
because  of  the  need  for  separate  displays  and  controls  and  for  signals  from  aircraft  sensors  that  either 
do  not  have  an  appropriate  output  or  are  not  easily  accessible. 

Recognizing  this  problem,  the  National  Aeronautics  and  Space  Administration  initiated  a  program  in 
1975  to  determine  the  feasibility  of  developing  an  integrated  avionics  system  suitable  for  general  aviation 
in  the  mid-1980s  and  beyond.  The  objective  was  to  provide  information  required  for  the  design  of  reliable 
integrated  avionics  that  would  enhance  the  utility  and  safety  of  general  aviation  at  a  cost  commensurate 
with  the  general-aviation  market.  The  program  has  emphasized  the  use  of  data  busing,  microprocessors, 
electronic  displays  and  data  entry  devices,  and  improved  functional  capabilities. 

.V„  &  Ltep,  4fi  agaLt  4  t-.Xf SU  hM,  M&jei.  U  YtC'.LyiK-U ,  l  «...  Ufch.4  ».<•*  idle  ‘LvtV- 
for  the  design  and  analysis  of  a  projected  advanced  avionics  system  (PAAS)  concept,  and  the  fabrication  and 
installation  of  a  demonstration  advanced  avionics  system  (DAAS),  which  was  capable  of  demonstrating  the 
most  Cittical  elements  of  i-wo,  frrtu  a  hMoA^uwned  uessna  4u2 o,  tw  iiFenyirre  generally  lation  ■aiix.'aft.  The 
general  requirements  for  DAAS  were  that  it  demonstrate  the  feasibility  of  designing  an  integrated  system 
that  would  provide  the  pilot  with  an  improved  capability  and  that  would  be  modular,  reliable,  and  easy  to 
maintain.  The  DAAS  acceptance  flights  were  conducted  at  Olathe,  Kansas,  in  June  1981,  and  an  operational 
evaluation  by  more  than  100  evaluation  pilots  and  observers,  representing  all  segments  of  the  general- 
aviation  community,  was  completed  in  May  1982. 

An  overview  of  the  program  with  a  summary  of  the  results  that  led  to  the  DAAS  specification  is  con¬ 
tained  in  Denery  et  al.  (1978).  A  preliminary  functional  description  of  DAAS  is  provided  in  Denery  et  al. 
(1979),  and  a  detailed  description  of  both  PAAS  and  DAAS  is  provided  in  Honeywell,  Inc.,  and  King  Radio 
t&.-p.  lv&Zb) .  F,-e1  imina.-y  results  of  the  flight  test  a  e  contained  in  ha.dy  et  a).  and  a 

complete  analysis  of  the  flight-test  results  will  be  published  later  this  year.  The  purpose  of  this  paper 
is  to  summarize  the  basic  features  of  DAAS  in  its  final  configuration  and  to  address  briefly  the  reliabil¬ 
ity,  me inta inabii ity ,  and  pilot  aeceptab  il  ity  of  the  uW&  concept  baseu  on  flight  expe/ iente. 


2.  PIlOT/SYSTEM  INTERFACE  DESIGN  GUIDELINES 

The  DAAS  pilot/system  interface  was  designed  to  provide  a  high  degree  of  flexibility  and  capability 

wni’le  III  i  II  i  III  I  Zing  cpc.ati^ual  complexity.  tile  ptiHiaty  Intel  lace  tifctweeli  urtfo  and  the  pilot  iS  achieved 

through  an  electronic  horizontal  situation  indicator  (EHSI),  an  integrated  data  control  center  (IDCC),  an 
assortment  of  function-  and  mode-select  buttons,  and  a  two-axis  slew  control  (Fig.  1).  A  more  complete 
aescriptioii  of  the  Instrument  panel  and  associated  dTsplays  and  controls  Ts  coiftained  in  5ec.  4.  Specific 
design  guidelines  included  (1)  commonality  of  electronic  display  formats  for  the  various  DAAS  functions; 
(2)  parallel  access  to  all  the  system  capabilities  or  functions  (parallel  access  means  that  the  pilot  can 
exercise  any  of  the  system  functions  directly  without  teeing  required  to  have  first  performed  other  func¬ 
tions  in  an  ordered  sequence);  (3)  minimization  of  the  requirement  for  the  pilot  to  change  the  displayed 

i '  •  'll  rtnjj  <  U.PV.1  1  ;‘l!  '  ' n  '  4 1  4  >  I  '  nl  Mf  f 2J\  I  •«  i  i  «•  '  'll.!  inf  rmj  r  i  jn  i  I  r.  I  ■ 

decision  maker. 

To  demonstrate  these  features,  DAAS  was  designed  to  include  (1)  an  automated  guidance  and  navigation 
carability,  using  VOR/DME  navigational  facilities;  (2)  standard  flight  control  with  navigation  coupling; 
(i)  #  flight  statu*  IwittW,  W  towput  .T-asslSted  1*ndbcok  tmupamiun*  vuth  a*  Height  ante  teaV&nte  a-nfi 
performance;  (5)  a  monitoring  and  warning  system  for  alerting  the  pilot  to  aircraft  mismanagement  and 
engine  anomalies;  (6)  storage  of  normal  and  emergency  checklists  and  operational  limitations;  (7)  a  data- 
liifk  capability  using  the  discrete  add  ess  beacon  system  (LdlBVj  of  Bode  t>  transponder  (the  TAA-pr upusefl 
replacement  for  the  ATCRBS  transponder);  (8)  maintenance  assistance;  and  (9)  a  simulation  mode  for  pilot 
training  and  familiarization.  These  capabilities  are  described  in  greater  detail  below. 
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3.  FUNCTIONAL  CAPABILITIES 

Guidance  and  Navigation:  The  DAAS  provides  for  (1)  standard  ILS/localizer  and  VOR/DME  navigation; 

(2)  area  and  vertical  navigation  with  respect  to  an  arbitrary  waypoint;  and  (3)  area  and  vertical  naviga- 
Tiuil  witn  f'fcupeCt  Lu  a  picdcf  meJ  fl  i  yiit^atfi  apfcxii  tfcd  tji  ci  xl  Vilfked  xf  tulmtrtfcu  t  ^ . 

The  DAAS  allows  a  combination  of  up  to  10  of  any  of  the  above  waypoints  to  be  stored  in  nonvolatile  mem¬ 
ory.  In  addition,  the  frequency,  station  identifier,  magnetic  variation,  elevation,  and  latitude  and 
Tony itudt  Tor  up  to  ten  navigation  aTaVlufiS  c3/i  tit  tto/refl.  Viiw  is  iiietfn&iii't^u  Si  liavnytti’ol 

facility  data  can  be  used  to  reduce  the  data  entry  required  for  defining  specific  waypoints. 

The  area-  and  vertical-navigation  capability  is  representative  of  current-generation  systems.  The 
measurements  from  a  single  VOR/DME  are  blended  with  true  airspeed,  heading,  and  barometric  altitude  to 
provide  an  improved  signal.  In  addition,  the  VOR  and  DME  Morse  code  identifiers  are  decoded  and  correlated 
with  the  desired  station  identifier  for  positive  station  identification.  The  navigation  outputs  include 
ground  speed,  ground  track,  winds,  and  aircraft  position  with  respect  to  the  selected  flightpath. 

Flight  Control:  The  flight-director/autopilot  is  a  digital  implementation  of  the  King  KFC  200  auto¬ 
pilot  modified  to  make  it  compatible  with  the  DAAS  navigation  system.  The  autopilot  modes  include  yaw- 
damper,  heading-seiect,  aititude-hoid,  altitude-arm,  vertical-navigation,  navigation-arm,  navigation- 
coupled;  approach-arm,  and  approach-coupled.  If  the  autopilot  is  coupled  to  the  area-navigation  function, 

I  «  Milo^r  ?  -tv'  >  •  vmmi  i»l  i  '■:<**  vfi  *o*  on.*  *  f  •  *"d  r 

courses. 

Flight  Status:  A  GMT  clock  and  fuel  totalizer  capability  is  provided;  together  with  the  area- 
navigation  capability  described  above  it  is  used  to  provide  the  pilot  with  a  complete  assessment  of  his 
status.  IneTthJec  arr.  t j,tTtra»uu  c  a, \1)  CTn  tw,  rtJth.d  vrf,.qs>,  poiw-t 

fuel  remaining;  (2)  the  distance  and  time  required  to  reach  each  waypoint  in  a  predefined  sequence  of  way- 
points;  and  (3)  the  estimated  time  of  arrival  and  fuel  remaining  at  each  of  these  waypoints. 

Computer-Assisted  Handbook  Computations:  The  DAAS  provides  a  capability  for  assisting  the  pilot  in 
rapid  computations  of  (1)  weight  and  balance,  (2)  takeoff  performance,  and  (3)  cruise  performance.  Inputs 
to  the  weight  and  balance  calculations,  such  as  fuel  load  and  passenger  weight,  are  entered  manually.  The 
ukAS  tnen  computes  tne  center  of  gravity  and  gross  weiyut  anc  aTer  ts  die  pi*lot  if  tne  computeu  values  are 
out  of  the  allowable  range.  Inputs  to  the  performance  calculation  can  be  performed  by  manual  data  entry 
or  automatic  entry  of  sensor  data  such  as  manifold  pressure  (MAP),  engine  rpm,  outside  air  temperature 
(OAT),  barometric  altitude,  winds,  and  aircraft  weight  (using  the  fuel  totalizer  function)  that  may  be 
available  in  DAAS  at  the  time  of  the  computation.  The  DAAS  then  provides  estimates  of  the  fuel  burn  rate, 
mileage  per  unit  of  fuel  burned,  percent  power,  true  airspeed,  and  ground  speed. 

Monitoring  and  Warning:  A  significant  contribution  of  an  integrated  avionics  system  is  its  ability  to 
correlate  the  measurements  from  different  sources  and  alert  the  pilot  to  abnormal  or  unsafe  conditions.  To 
demonstrate  this  concept  DAAS  includes  an  engine-monitoring  function,  an  aircraft-configuration-monitoring 
function,  and  a  ground-proximity  warning  function 

The  engine-monitoring  function  provides  continuous  monitoring  of  manifold  pressure  and  engine  rpm. 

The  aircraft-configuration-monitoring  system  continually  monitors  the  position  of  the  doors,  landing  gear, 
cowl  flaps,  wing  flaps,  auxiliary  fuel  pumps,  and  trim  as  a  function  of  aircraft  state.  In  both  cases  the 
pilot  is  alerted  to  out-of-tolerance  conditions. 

The  ground-proximity  warning  function  is  based  on  Mode  1,  defined  in  ARINC  Specification  594-1;  it 
alerts  the  pilot  to  excessive  rates  of  descent  with  respect  to  the  terrain. 

Normal  and  Emergency  Checklists  and  Operating  Limitations:  The  normal  and  emergency  checklists  and 
operational  limitations  are  stored  in  DAAS  so  that  the  pilot  can  quickly  and  easily  refer  to  them. 

Data  Link:  The  ATC  communication,  weather,  reporting,  ATC  test  messages,  or  weather  information  at 
destination  can  be  communicated  to  the  pilot  via  the  transponder  data  link  and  displayed  on  an  electronic 
display.  Future  plans  call  for  exercising  this  capability  at  the  FAA  Technical  Center  in  Atlai.Lic  City, 
N.J.,  with  the  test  ground  system.  In  order  to  introduce  the  demonstration  pilots  to  the  capabilities  of 
DABS,  certain  of  its  features  are  simulated  in  the  DAAS. 

Maintenance  Assistance:  The  DAAS  includes  built-in  test  (BIT)  to  assist  maintenance  and  fault  iso- 
\ a L I .  Tf.c  lA  t  1 L  \i^t»igi.eu  Lx  f fit i: i L 6 Lx  /waix/. .VLt  avion  x 1  atixAiiv.,  L _W ix,  Tr,  LYic  \.unb 
advanced  general -aviation  maintenance  concepts  that  would  exist  in  PAAS.  The  DAAS  also  includes  an  auto¬ 
matic  functional-test/fault-localization  at  powerup  or  when  commanded  by  the  operator,  which  identifies 
'iiVcb  T  wii-s,  tffrfi  m  itrtefefcVm:  twitt-runA',  t-M  ttrvtft/Vi-Vtj  ifl.-itr,  Vmjtvs  ttic.  tasting  -ul 

devices  when  operator  actions  or  observations  are  necessary  to  complete  a  test.  For  example,  electronic 
display  test  patterns  are  included  in  DAAS  to  demonstrate  interactive  testing. 

Simulation  Mode:  By  selecting  the  simulation  mode,  the  DAAS  can  be  exercised  on  the  ground  for  pilot 
training.  The  pilot  controls  the  simulated  aircraft  through  the  autopilot  mode-select  panel.  All  DAAS 
displays,  controls,  and  functions  can  be  demonstrated  in  the  simulation  mode. 


4.  DAAS  DISPLAYS  AND  CONTROLS 

The  DAAS  instrument  panel  is  shown  in  Fig.  1.  The  DAAS  comprises  all  the  instruments  on  the  left  side 
of  the  panel,  the  engine  instruments,  the  integrated  data  control  center  (IDCC),  and  the  radios  located  in 
the  center  of  the  panel.  The  two  electronic  displays  are  an  electronic  horizontal  situation  indicator 
(EHSI)  and  the  IDCC.  The  EHSI  provides  a  function  similar  to  that  of  an  electromechanical  HSI  but  also 
serves  as  an  electronic  map.  The  IDCC  display  is  used  for  alphanumeric  messages  and  is  the  primary  means 
by  which  the  pilot  communicates  witn  DAAS.  The  EHSi  and  IDCC  are  discussed  in  greater  detail  later  in  this 
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section.  The  other  instruments  are  already  used  in  general  aviation;  based  on  earlier  configuration 
studies  (Denery  et  al.,  1978),  the  replacement  of  these  instruments  with  electronic  displays  would  be 
4n  Mk  demcfistfatioi  p*W|TWi.  and  wuU  it  cabcta.UiUy  v  AjttWifc*. 

DAAS  is  a  research  system,  the  right  side  of  the  panel  is  provided  with  a  set  of  independent  conventional 
instruments  for  use  by  a  safety  pilot. 

EHSI:  The  EHSI  used  in  DAAS  is  a  4.5-  by  4.5-in.  monochromatic  CRT  raster  scan  display.  It  has  two 
formats.  One,  which  is  activated  when  the  VOR  or  ILS  navigation  mode  is  selected,  provides  angular  devia¬ 
tion  from  the  desired  course  in  much  the  same  manner  as  contemporary  horizontal  situation  displays.  The 
attar,  mp.U9  it  tUintoi  at  otA  <i  •  ■ctTk.-an  •«<♦»?  >nn 

The  scaling  choices  for  the  moving-map  presentation  include  terminal  area,  2  n.  mi. /in.;  en  route, 

8  n.  mi. /in.;  and  a  40  n.  mi. /in.  scale  to  assist  the  pilot  in  overall  flight  planning. 

T  tic  LIlGl,  wlti.  a  HuTina-Miap  presentation  a..j  LI  ill  tOntruVs,  is  illustrated  in  Tig.  2.  WtsT.  -4  Its 
symbols  are  self-explanatory.  The  scale  across  the  top  of  the  display  with  the  "270"  digital  readout 
gives  aircraft  heading.  The  selected  heading  is  indicated  by  the  heading-select  bug  on  the  heading  scale 

ami  Cue  uiyiLdi  anu  ylapllical  p.  c^ciaa  L  i  uli  ill  tti  uppd  ic'il  pu.Vic'n  ui  Tlic  uiapiaj.  KaOiu  'oltlXuQc  13 

displayed  in  the  upper  right-hand  corner  when  the  aircraft  is  lower  than  2,500  ft  above  the  ground.  Data 

pertinent  to  the  active  waypoint  are  shown  along  the  left  side  of  the  display.  These  data  include  the 

min  itiiuni  descent  altitude  Oi  decision  neiyiit  if  tiie  waypoint  is  an  appi  oacn  ..aypunn,,  tiie  active  naypoi.it 
number;  the  course,  distance,  and  time  to  or  time  from  the  active  waypoint;  the  waypoint  altitude  (which 
is  used  for  both  altitude  select  and  vertical  navigation);  and  the  VOR/DME  receiver  being  used  for  naviga¬ 
tion.  The  numeral  "1"  below  the  indicated  course  (CRS  295)  indicates  that  the  aircraft  is  on  the  inbound 
course;  an  outbound  course  would  be  indicated  by  the  numeral  "2."  The  WP  AVAIL  display  on  the  lower  right 
side  alerts  the  pilot  when  the  navigation  station  associated  with  the  next  waypoint  is  received,  based  on 
a  periodic  scan  of  the  frequency  by  the  DAAS  radios.  The  VTA  scale  along  the  riqht  side  of  the  display  is 
used  to  show  the  vertical  angle  between  the  current  aircraft  position  and  the  next  waypoint.  When  the 
vertical  navigation  mode  is  engaged,  the  actual  deviation  from  the  derived  vertical  path  is  shown  on  the 
electromechanical  attitude  director  indicator.  The  wind  magnitude  and  direction  are  depicted  on  the  lower 
right  portion  of  the  display.  The  dashed  line  projecting  from  the  aircraft  symbol  indicates  projected 
yfuuna  track,  aisu  iiiuwu  rTt  syiiUju'a  TuT  the  waypoints,  uie  courses  coimtcT-itiy  seyue.ixiai  Way puirttS , 
and  navigation  facilities  within  the  range  of  the  display. 

The  controls  for  the  EHSI ,  which  are  located  adjacent  to  the  display,  include  a  tw;-axis  slew  control 
ffiia  tMC!  function  *t=/s.  TV.t  slew  to‘n^*?o!  is  uScj  ha  (1)  slaw  the  map  pfLScfihahiCiTi  laheitliji  e.  lufigShufli- 
nally  so  that  the  pilot  can  review  the  predefined  flightpath  beyond  the  normal  range  of  the  display  or 
(2)  control  a  cursor  on  the  EHSI  display  for  graphically  defining  waypoint  coordinates.  The  function  keys 
allow  the  operator  to  (1)  select  a  heading-up  or  north-up  map  presentation  (HDG/NOR);  (2)  designate  whether 
the  slew  control  is  used  for  slewing  the  map  presentation  or  controlling  a  cursor  for  graphic  definition 
of  'it  i.  jfHfttjUrj  fHflfyptm  i }  (j  i  autuieiU*!  rvoftfier  till'  if  fi  Act  tLwd  (m  ti>  «.  *  - 
mal  position  (MAP  RTN) ;  (4)  add  or  delete  the  presentation  of  an  active  waypoint  bearing  needle  from  the 
display  (WP  BRG);  (5)  review  the  planned  flight,  using  the  map-slew  feature  during  preflight  when  radio 
signal*  w  :«Jt  -wi'e'iU  enfl  (f .1  u.fwct  Ui«  iiifi  v:;l(  4  (1  It”  <0  W,  V.  W4 

IDCC:  The  IDCC  is  shown  in  Fig.  3.  The  cathode  ray  tube  is  identical  to  that  used  in  the  EHSI  dis¬ 
play.  The  display  format  provides  16  lines  of  32  characters.  The  two  bottom  lines  are  reserved  for 
scratch  pad,  warning  messages  from  the  monitoring  and  warning  system,  and  error  messages  resulting  from 
invalid  data  entries.  The  two  top  lines  are  reserved  for  the  title  of  the  selected  IDCC  display  presenta¬ 
tion.  The  remaining  portion  of  the  display  provides  two  columns,  each  with  four  data  entry  or  selection 

itm*  tatrmrta*  >4  it*  (U,  it  ***'  ♦«*-:.  *'^,5  J  it*  f.Us^X *4. 

The  IDCC  also  contains  a  set  of  dedicated  function  keys  along  the  top.  These  keys  are  used  to  call  up 
specific  pages  on  the  IDCC  display  (PAGE  SELECT)  or  to  execute  specific  functions  associated  with  the  DAAS 
tiavigaV'oi,  eeyttrfHty  (IM),  wnie.i  induce  activating  the  Selected  wtypulirt.  ut,  the  iuCC  oisvlh,,  V<iLL), 


activating  automatic  course  change  between  inbound  and  outbound  courses  (AUTO  CRS  SEQ);  manual  selection 
between  inbound  or  outbound  course  (CRS  SEL);  and  automatic  generation  of  an  inbound  course  from  the  air¬ 
craft  present  position  to  the  active  waypuinh  (LkI  Din  TV). 

The  keys  at  the  bottom  left  of  the  IDCC  are  used  for  data  entry.  A  telephone-type  keyboard  format 
with  three  letters  on  each  key  is  used  for  alphanumeric  entries.  The  alpha  ambiguity,  which  results  f-om 
having  three  letters  on  each  key,  is  resolved  by  touching  one  of  the  three  buttons  along  the  bottom  of  the 
keyboard  (Fig.  3),  thus  designating  the  left,  middle,  or  right  letter  in  a  group.  A  toggle  is  located  to 
the  right  of  the  keyboard  for  rapid  change  in  the  displayed  Information  from  one  page  to  another,  if  a 
sequence  of  pages  is  involved  in  a  particular  function. 

Figure  4  shows  an  example  of  an  IDCC  display  format.  This  display  is  presented  for  the  waypoint 
which  is  currently  being  used  for  navigation  when  the  WP  DATA  key  at  the  top  of  the  IDCC  is  pressed.  This 
U  nUtmf  Vi  H  thk  «cUw  mypofnt  taytut  t  l  U  yrvmxjtA  u  if*  dtHw*  It*  mw 

is  first  turned  on.  The  label  at  the  top  of  the  display,  "WP  DATA  P  1  of  10,"  identifies  the  page.  The 
subtitles  adjacent  to  the  asterisks  Identify  the  function  of  the  eight  bezel  keys.  Two  types  of  bezel  key 
twhUiWi  dh*  UtaltWlod  -page-  dVpffciwnem  *nd  ersjves 

in  the  second  column)  and  mode  select.  To  enter  alphanumeric  data,  the  pilot  predesignates  the  parameter 
to  be  changed  by  touching  the  key  alongside  the  appropriate  subtitle,  keying  in  the  desired  data,  reviewing 
them  in  the  scratch-pad  portion  of  the  IDCC  display,  and,  upon  approval,  touching  the  enter  key  (ENTR)  on 
the  IDCC.  Upon  touching  the  bezel  key  alongside  the  appropriate  title,  an  arrow  appears  to  the  left  of  the 
quantity  to  be  changed.  When  two  data  entries  are  associated  with  a  single  key,  such  as  the  frequency 
;fi<LV7  *fi6  Station  elevation  (tttv ) ,  the  ar,0»  can  he  advanced  Irum  fidty  to  Let?  hy  touch  my  vne  oezei  "key 
a  second  time  cr  by  touching  ENTR.  As  mentioned  above,  on  touching  ENTR,  the  quantity  in  the  scratch  pad 
will  be  entered  into  the  location  designated  by  the  arrow.  If  the  scratch  pad  is  clear,  the  arrow  is 
advanced  without  itteMng  the  stored  value,  hn  example  et  the  mo8e-se"IeCh  ’Tunction  is  provided  by  the  "MBA 
OR  DH  or  NAV  MODE  subtitles.  By  using  the  appropriate  bezel  key,  the  pilot  has  the  option  of  (1)  designat¬ 
ing  the  waypoint  as  being  an  MDA  or  DH  waypoint  or  (2)  navigating  in  a  VOR/ILS  mode  (VOR/ILS)  as  opposed 
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to  an  area-navigation  mode  (RNAV).  The  selected  mode  is  indicated  by  the  >  symbol  which  is  toggled 
between  the  two  choices  by  sequential  pressing  of  the  bezel  key. 

In  order  to  minimize  data  entry,  DAAS  automatically  enters  data  where  possible.  As  an  example, 
assume  that  a  waypoint  is  referenced  to  a  navigation  station  whose  data  have  been  previously  stored  by 
using  the  NAV  AID  DATA  page.  Then,  on  entering  the  navigation  station  reference  number  (NAVAID  NO),  the 
prestored  station  identification  (ID)  and  frequency  and  elevation  (FREQ/ELEV)  are  automatically  entered  on 
the  w-iypoint  data  page.  In  addition,  if  a  sequence  of  the  waypoints  is  entered  and  referenced  to  previ¬ 
ously  stored  navigation  station  data,  the  DAAS  assumes  these  waypoints  are  connected,  and  the  DAAS- 
computed  inbound  and  outbound  courses  (CRS1/CRS2)  are  automatically  entered.  The  pilot  can  change  any  of 
these  calculated  data  by  using  the  manual  data  entry  procedure  described  in  the  previous  paragraph. 

The  IDCC  cruise  performance  capability  is  another  good  example  of  how  the  IDCC  is  used.  The  CRUISE 
PERFORMANCE  page  (Fig.  5)  is  accessed  by  pressing  the  PERF  select  key  at  the  top  of  the  IDCC,  which  brings 
up  a  menu  page  listing  the  various  possible  performance  computations  as  subtitles  adjacent  to  the  bezel 
keys.  Pressing  the  appropriate  bezel  key  displays  page  1  of  the  two  pages  associated  with  the  cruise  per¬ 
formance  shown  in  Fig.  5.  The  first  page  is  used  for  data  entry,  and  the  results  of  the  computation  are 
presented  on  the  second  page.  The  first  entry  on  page  1  is  labeled  DATA  ENTRY;  it  allows  the  pilot  to 
designate  whether  he  will  enter  the  data  manually  (MAN)  or  automatically,  using  the  available  sensors 
(AUTO).  As  an  example,  if  the  pilot  selects  AUTO,  the  altitude  is  entered  based  on  the  barometric  altim¬ 
eter  reading;  winds  and  course  are.  taken  from  the  navigator;  OAT  is  taken  from  the  temperature  sensor; 

A/C  WT  is  taken  from  the  DAAS-computed  aircraft  weight,  based  on  the  fuel  totalizer  function;  and  power  is 
computed,  based  on  engine  rpm  and  manifold  pressure.  By  toggling  DATA  ENTRY  to  MAN,  these  values  are 
retained  and  the  pilot  can  manually  change  any  of  the  entries  to  meet  his  particular  requirements.  The 
results  of  the  performance  computation  are  presented  on  page  2  (P2  OF  2),  which  is  accessed  by  using  the 
IDCC  BACK-FWD  switch  in  the  lower  part  of  the  IDCC. 


5.  SYSTEM  ARCHITECTURE 

A  schematic  for  PAAS,  on  which  DAAS  was  based,  is  shown  in  Fig.  6.  PAAS  is  a  reconfigurable,  multi¬ 
processor  system  organized  around  a  dual  bus.  Each  processor,  referred  to  as  a  computer  processor  unit 
(CPU),  consists  of  a  microprocessor,  an  interrupt  controller,  a  clock,  a  bus  interface  module,  a  read-only 
memory  (ROM),  and  random  access  memory  (RAM).  The  system  is  designed  so  that  each  processor  is  assigned  a 
specific  set  of  tasks.  The  functional  programs  reside  in  the  nonvolatile  memory.  When  power  is  turned  on, 
the  bus  controller  (CPU-1)  supervises  the  loading  of  the  programs  into  the  individual  CPU  RAM  memories. 
System  reliability  is  achieved  by  providing  a  second  bus,  with  bus  control l'"',  I/O,  and  reconfiguration 
processing  unit  (CPU-2),  to  act  as  a  backup  for  the  primary  bus,  and  a  spare  processor  (CPU-7)  to  act  as  a 
backup  for  the  other  processor  units  that  do  not  have  direct  interface  with  external  sensors  (such  as 
CPU-6  and  CPU-10).  Upon  detecting  and  isolating  a  failed  processor  unit  other  than  the  bus  controllers  or 
CPU-6  and  CPU-10,  the  active  bus  controller  loads  the  program  assigned  to  the  failed  processor  into  the 
spare  processor.  Redundancy  for  CPU-6  and  CPU-10  could  be  provided  by  multiplexing  the  respective  sensor 
aWcfltt  witr,  ttr*  spart  proteSSW ,  as  was  8ofit  far  Wit  tV&i,  CWJ  %,  vi  W  ikA  CT\5  YtOwvr^r ,  LMs 
redundancy  is  not  provided  since  these  functions  are  not  considered  to  be  flight  critical;  moreover,  these 
particular  sensors  have  a  significantly  lower  reliability  than  the  associated  CPU. 

fi  akuih  •  f  *  Hv  t U*  <•  f't’iilfrf!  xn  Hw  .  urijpt '  *  tt  u  '-t 

uses  a  single  bus;  the  sensors  and  autopilot  mode-select  panel  are  interfaced  directly  with  the  autopilot, 
CPU-3;  CPU-2  is  used  only  as  the  radio  adapter  unit  (RAU).  These  simplifications  were  made  in  order  to 
reduce  development  costs  while  retaining  the  capability  to  evaluate  (1)  the  pilot  system  interface;  (2)  the 
multi  processor/bus -oriented  architectural  concept;  and  (3)  certain  features  of  the  PAAS  reconfiguration 
concept. 

Thu  DAAS  uses  the  IEEE  488  bus.  This  bus  was  selected  because  of  the  availability  of  low-cost  LSI 
interface  chips  and  the  flexibility  provided  by  the  protocol.  The  computer  processor  units  (other  than 
CPU-2)  use  the  Intel  8086,  16-bit  microprocessor  and  have  2  K  of  16-bit  ROM,  and  4  K  to  16  K  of  16-bit  RAM. 
An  Intel  8048,  8-bit  microprocessor  is  used  in  CPU-2.  Electrically  erasable  PROM  (EEPROM)  is  used  for  the 
nonvolatile  memory. 


6.  PROGRAM  AND  FLIGHT-TEST  RESULTS 

6.1  Pilot  Evaluation 

A  primary  purpose  of  the  DAAS  program  was  to  conduct  an  operational  evaluation  of  the  DAAS  concept. 

The  major  question  being  addressed  was  whether  the  added  capability  provided  by  an  integrated  avionics  sys¬ 
tem  could  be  effectively  used  by  the  pilot.  Sixty-four  flight  demonstrations,  in  which  more  than  100  eval¬ 
uation  pilots  and  observers  participated,  were  conducted  to  answer  this  basic  question.  At  the  conclusion 
of  each  flight  the  subjects  were  debriefed  and  asked  to  complete  a  questionnaire.  Preliminary  results 
from  these  tests  are  contained  in  Hardy  et  al.  (1982).  (A  detailed  analysis  is  in  preparation.)  In  sum¬ 
mary,  a  significant  majority  of  the  pilots  who  participated  clearly  felt  that  DAAS  was  representative  of 
the  way  avionics  were  evolving  and  that  the  added  capability  could  be  effectively  used  to  improve  the 
safety  and  utility  of  the  aircraft.  The  major  concerns  that  were  expressed  regarded  the  training  that 
Wbuld  fce  requited  to  utnlie  tlte  full  C&tAblli\y  ul  :> uui i  iysteffi.i  oud  tilt  at>ilii.y  tj  apply  tliiS  Irainii.g  to 
the  operation  of  other  but  similar  systems. 

6.2  Architecture  Evaluation 

Modularity;  The  PAAS  concept  is  highly  modular  because  of  the  bus  architecture  and  multiprocessor 

Us  sfrtr-ei  ,,  eofftr&YSj  Mid  verftvrv  Vne  irwhrrar-Uj  ws  n,  atom,-,  tin. 

DABS  function.  Although  the  DABS  capability  was  added  several  months  after  the  final  design  was  completed 
and  fabrication  started,  it  was  easily  implemented  by  adding  CPU-6  to  the  system  bus,  adding  a  software 
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module  to  the  IOCC  for  display  and  control  of  the  DABS  sensor,  and  adding  the  address  of  the  DABS  function 
to  the  bus  controller,  CPU-1. 

Reliability:  The  PAAS  is  a  fail -operational  design.  Reliability  of  the  PAAS  autopilot  and  naviga¬ 
tion  functions  was  computed  to  be  9,260  hr  between  loss  of  function  based  on  a  1-hr  mission.  A  similar 
analysis  on  contemporary  flight  control  and  navigation  systems  showed  an  expected  201  hr  between  loss  of 
function. 

Since  DAAS  is  a  one-of-a-kind  system,  the  reliability  experience  obtained  during  the  tests  cannot  be 
extrapolated  to  PAAS.  However,  it  is  worth  noting  that  DAAS  was  tested  in  the  Ames  Cessna  402B  for  a 
period  of  over  6  months,  during  which  time  more  than  200  flight  hours  and  500  power-on  hours  were  accumu¬ 
lated.  During  this  period  there  were  a  few  minor  problems  traceable  to  the  commercial -grale  card-edge 
connectors  (corrected  by  reseating  the  cards  and  reloading  the  program).  There  were  no  failures  of  DAAS 
hardware  that  required  replacement  of  a  component.  Of  the  60  flight  demonstrations  that  were  scheduled 
none  was  cancelled  because  of  a  DAAS  hardware  or  software  failure.  The  PAAS-reconfiguration  concept  was 
tested  by  artificially  inserting  faults  in  the  CPU-5.  Reconfiguration  was  complete  within  1  sec  of  fault 
insertion.  The  spare  processor  (CPU-7)  was  successfully  loaded  and  the  mission  was  not  affected. 

Maintainability:  The  self-test  and  diagnostic  features  of  PAAS  have  the  potential  of  isolating  fail¬ 
ures  down  to  the  module  level.  Because  of  the  fail -operative  nature  of  the  system  design,  a  module  can  be 
removed  for  repair,  as  in  contemporary  systems,  while  retaining  an  operative  system.  As  mentioned  above, 
during  the  DAAS  flights  there  were  no  hardware  failures  that  required  maintenance;  therefore,  the  mainte¬ 
nance  features  were  not  completely  tested.  However,  simulated  faults  were  easily  identified,  using  the 
available  interactive  functional  test  and  fault-localization  capability. 


7.  CONCLUDING  REMARKS 

A  fully  integrated,  multiprocessor,  advanced  avionics  system  concept,  DAAS,  was  designed,  built,  and 
flight  tested  in  a  Cessna  402B. 

The  pilot/system  interface  was  designed  to  provide  a  high  degree  of  flexibility  and  capability  while 
minimizing  the  operational  complexity.  Specific  design  guidelines  included  (l)  commonality  of  IDCC  display 
format  for  the  various  functions;  (2)  parallel  or  direct  access  to  all  system  capabilities,  as  opposed  to 
sequential  access;  (3)  minimization  of  the  necessity  to  change  display  formats  during  normal  flight;  and 
(4)  designing  DAAS  to  be  a  source  of  information  but  not  a  decision  maker.  Based  on  the  pilot  evaluations, 
these  guidelines  appear  appropriate  for  the  design  of  avionics  for  this  class  of  aircraft  and  mission. 

The  PAAS  architectural  concept  proved  to  be  highly  reliable,  maintainable,  and  modular.  State-of-the- 
art  microprocessor  technology  is  easily  capable  of  handling  the  various  functions  required  in  general  avia¬ 
tion.  The  use  of  a  bus  architecture  allows  growth  and  sharing  of  limited  sensor  and  display  resources 
between  the  many  subsystems  that  may  be  included  in  a  future  system.  The  use  of  a  spare  processor  for 
improving  reliability  by  dynamic  reconfiguration  was  successfully  demonstrated. 
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Figure  3.  Integrated  data  control  center. 
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DISCUSSION 

R.Q.Laws,  UK 

In  the  presented  architecture,  re-configuration  using  the  spare  CPU  is  apparently  achieved  by  downloading  program 
into  the  spare  CPU  via  the  databus.  Is  this  indeed  true? 

Author’s  Reply 

Yes. 


R.Davies,  Ca 

(1)  With  respect  to  the  DAAS  questions  asked  of  the  pilot  community,  none  required  specific  answers  regarding 
what  cost  data  would  be  acceptable  over  a  current  standard  general  aviation  suite.  I  suspect  that  those  owner- 
pilots  of  GA  aircraft  that  pay  for  their  own  avionics  would  have  a  lower  dollar  figure  than  those  for  whom  an 
aircraft  is  provided  and  equipped  by  someone  else. 

(2)  What  type  of  data  bus  was  used  and  does  NASA  have  any  recommendations  as  to  what  GA  should  use  in  the 
future?  Should  there  be  a  general  aviation  standard  data  bus  or  would  NASA  recommend  GA  involvement  in 
ARINC/AEEC  development  of  standards  such  as  the  airlines  ARINC  700  series  of  “black  boxes”  with  ARINC 
600  connectors  (and  F3)  on  an  ARINC  429  bus? 

Author’s  Reply 

( 1 )  The  question  is  very  pertinent  but  was  not  asked  of  the  participating  pilots. 

(2)  The  DAAS  system  used  the  IEEE  488  bus  with  the  Intel  8086  microprocessor  as  the  basic  computing  element. 
The  IEEE  488  bus  was  selected  because  of  the  availability  concept.  The  DAAS  project  did  not  directly  address 
the  issue  of  a  data  bus  standards,  however,  the  general  feeling  expressed  by  the  FAA,  NASA  and  members  of 
the  General  Aviation  community  involved  with  the  project  was  that  the  premature  application  of  standards  to 
this  market  could  result  in  increased  costs.  It  was  felt  that  standards  should  evolve  naturally  as  a  result  of 
market  forces  and  should  not  be  forced  on  to  the  manufacturers. 


M.Burford,  UK 

You  have  successfully  demonstrated  the  use  of  the  spare  CPU  to  give  a  fault  tolerant  system.  When  the  system  is 
dynamically  reconfigured,  may  I  ask  how  many  words  of  memory  are  typically  being  switched  over  the  bus  during 
this  initial  phase. 

Author’s  Reply 

The  number  of  words  transferred  over  the  bus  will  depend  on  which  processor  has  failed.  For  these  tests  the  number 
of  16  bit  words  ranged  between  8  k  and  16  k. 


K.F.Boecking,  Go 

(1)  The  PAAS  architecture  shows  a  redundant  bus  system.  Do  you  transmit  all  messages  on  both  buses 
simultaneously  or  do  you  use  the  second  bus  as  a  standby  system? 

(2)  How  do  you  present  an  emergency  situation  to  the  pilot? 

Author’s  Reply 

(1)  The  PAAS  concept  is  based  on  transmitting  all  messages  on  both  buses  to  provide  dual  redundant  inputs  to 
detect  faults  with  high  confidence.  The  PAAS  data  bus  can  be  switched  manually  from  dual  operation  to 
individual  use  of  either  bus. 

(2)  Warning  and  caution  conditions  are  brought  to  the  pilot’s  attention  by  a  red  warning  light  and  an  amber 
caution  located  near  the  ADI.  These  direct  the  pilot’s  attention  to  a  dedicated  portion  of  the  integrated  data 
control  center  where  a  caution  or  warning  message  is  displayed.  The  pilot  pushes  a  message  acknowledge 
button  to  extinguish  the  lights.  Multiple  warning  And  caution  messages  are  stored  in  circular  queues  with  the 
warning  message  queue  having  display  priority.  Pushing  the  message  acknowledge  button  rotates  the 
message  queues.  Messages  stay  in  their  respective  queue  until  the  conditions  causing  them  are  removed,  at 
which  point  the  messages  are  automatically  deleted  from  the  queue. 
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SUMMARY  OF  SESSION  IV 
SYSTEM  INTEGRATION  AND  SYSTEM  TEST 

by 

W.H.Vogl 
Session  Chairman 


Although  one  would  derive  from  the  topic  that  this  session  was  mainly  hardware  oriented,  very  soon  it  became 
apparent  that  not  the  description  of  test  performance  and  results  was  placed  in  the  foreground,  but  rather  that  modern 
methodologies  for  integrating  very  complex  hardware  and  software  systems  have  been  worked  out.  Starting  of  course 
with  some  general  experience  gained  during  the  development  of  existing  and  forthcoming  Weapon  Systems  nearly  all 
papers  concentrated  finally  on  what  was  considered  the  demands  for  future  engineering  work:  to  develop,  provide  and 
apply  computer-aided  integration,  simulation  and  test  methods  and  facilities  with  all  the  hardware  in  the  loop.  Making 
use  of  the  advantages  of  such  applications  it  is  thought  that  development  costs  for  highly  complex  systems  can  be  kept 
to  an  acceptable  level,  and  that  safety  -  and  with  this,  confidence  in  these  systems,  can  be  considerably  increased.  In 
this  latter  view  a  considerable  part  of  the  discussion  was  also  devoted  to  the  man-machine  interface  investigations. 

The  session  started  with  paper  No. 35,  titled  “Mdthodes  de  Ddveloppement  du  Systeme  de  Navigation  et  d’Armement 
du  Mirage  2000”  prepared  by  Mr  Boncorps  from  Avions  Marcel  Dassault-Breguet  Aviation,  and  presented  by 
Mr  Connan.  Being  in  the  Mirage  2000  development  and  integration  business  from  its  beginning,  the  author  reviewed  the 
methods  applied  to  achieve  the  design  aims.  In  particular,  the  paper  addressed  two  main  elements  which  helped  to  over¬ 
come  the  inherent  engineering  problems  for  integrating  such  a  complex  system:  first,  close  organisational  relationship 
between  the  designers  and  the  users  has  to  be  established  from  the  beginning  of  the  project,  to  avoid  misdirection  of  any 
design  effort  and  to  meet  the  commonly  defined  requirements.  Of  the  same  level  of  importance,  however,  is  the  use  of 
highly  developed  simulation  and  support  devices  for  dynamic  integration  on  the  ground  and  in  the  air. 

Paper  No.36  “Crew  Station  Evaluation  in  a  Dynamic  Flight  Simulation  Facility”  by  Mr  J.Eyth,  Jr  of  the  Naval 
Air  Development  Center,  explained  the  unique  capabilities  and  design  of  the  Dynamic  Flight  Simulation  and  Crew  Station 
Evaluation  Facility  built  at  Warminster,  as  they  pertain  to  avionics  system  development  and  validation.  The  paper 
amplified  the  infermation  tabled  earlier  during  this  symposium,  to  the  extent  to  really  assess  the  system  design  with  the 
man  in  the  loop  in  a  flight  envelope  which  by  far  exceeds  that  of  in-flight  simulation  or  flight  tests.  The  simulator  enables 
hazardous  flight  regimes,  such  as  spins  and  departures,  to  be  investigated  in  a  repeatable,  statistically  accurate  fashion,  with 
regard  to  advanced  aerodynamic  profiles,  cockpit  displays  and  controls,  crew  systems  and  weapon  systems. 

In  paper  No. 37,  on  "Concepts  for  Avionics  and  weapu..  Integration”,  Dr  F.Kaestner  from  Messerschmitt- 

Boelkow-Blohm  reviewed  the  methods  and  facilities  applied  to  the  avionics  and  weapon  integration  the  PANAVIA 
Tornado  aircraft.  From  this  proven  concept  he  derived  detailed  ideas  how  to  respond  to  the  challenges  which  will  anse 
from  advanced,  even  more  complex  airborne  systems.  The  overall  aim  is  to  develop  and  install  facilities  which  will  allow 
system  hardware  and  software  testing  and  validation  under  environmental  conditions  which  are  as  close  as  possible  to  the 
actual  mission  enviiuiuhsmt  thus  avoiding  a  high  number  of  time-cunronihig,  expeustvc  flight  tests  during  the  devttopiuehl 
phase.  For  the  actual  development  flying  it  remains  to  demonstrate  that  the  system  works  to  its  specification. 

'iper  N  is  "ttinJutjrv-i'n-r.hr-i;  utjp  Sfuuiknix  i  Teuhnaqjjt*  uiud  in  thp  uf  tLu  Srt  linrif  foHrwii. 

System",  co-authored  by  Messrs  M. Mansell,  W.J.Quinn  and  C.J. Smith,  of  British  Aerospace,  Brough  Division,  was 
presented  by  Mr  Mansell.  The  paper  described  the  techniques  which  were  adopted  to  ensure  that  the  hardware  and 
associated  software  were  tested,  validated  and  integrated  into  the  aircraft  in  an  efficient  and  effective  manner.  Although 
the  development  methods  using  the  simulation  with  airborne  hardware  in  the  loop  are  well  established  techniques,  each 
new  weapon  system  produces  a  different  set  of  problems  which  require  specially  tailored  measures  to  cope  with.  The 
Dynamic  Development  Rig  is  capable  of  driving  the  avionic  navigation/attack  hardware  in-the-loop  during  aircraft  attack 
profiles.  The  basic  sensors  were  replaced  by  injection  of  computerized  sensor  signals  into  the  system.  The  dynamic 
Jevrioprnwit  facility  has  prowei  useful  for  both  eariy  evaUiitks  rJ.  sw  spun  protkn.  aie*  ur.J  •:.«*  cyctw. 

development  and  has  significantly  reduced  the  total  flying  hours  required  on  such  a  development  programme. 

Paper  No.39  dealing  with  “Simulation  Requirements  to  Support  the  Development  of  a  Fault  Tolerant  Avionic 
System”  was  given  by  Mr  j.Shaw  ol  Nolthrop  Corporation  and  described  the  Northrop  Avionics  si  nutation  package 
(Executive  Support  System)  which  has  been  designed  to  support  the  development  of  fault  tolerant  avionic  systems  and 
is  currently  used  for  the  F-5G,  F-18L  and  F-20  avionics  models.  It  provides  a  mechanism  for  developing  and  testing 
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several  avionic  core  configurations  as  well  as  avionic  simulation  and  application  modules.  Through  an  inter-active  inter¬ 
face  the  user  is  very  flexible  in  configuring  the  core  avionics  system  as  desired.  He  is  able  to  define  whether  centralised 
or  urftiu/nl  .it  ^  i iiiv  . .j  ] i n i  ii i  ii  u  v  dp'p in ii  in  tin  system  ix  cum  1  in  u ltp ^ un  .  <y  st ciu  cmi  n  -umi y  tanoreu  to 
various  applications,  configurations  and  anticipated  mission  scenarios.  The  ongoing  enhancement  is  aimed  at  providing 
one  pr%lam  to  stimulate  multi  le  airframes  or  multi  ,  •  rr»<v»«vn£  <»1ement\  i"  mulfif  le  user  q  eeifiaWe  i-onfi  jiratinns 

Paper  No.40  “Software  Testing  for  Safety  Critical  Systems”  was  prepared  and  presented  by  Herr  J. Stocker  of 
Messerschmitt-Boelkow-Blohm,  Military  Aircraft  Division.  From  the  title  of  this  paper  and  when  addressing  the 
i’ANMflA  “f otmnJc ” M  tttt  slbu* <*k  «l  riR«t  totpoKurf  aspem  cl  tttr 

development  and  operation  of  an  aircraft  which  was  optimised  for  TF  flying  in  extremely  low  altitudes:  to  provide  the 
high  level  of  confidence  into  the  system  which  is  necessary  for  such  operation  profile.  This  aim  is  achieved  by  thorough 
through-testing  using  powerful  and  capable  test  facilities  and  adequate  hardware  and  software  test  concepts.  The  paper 
outlined  the  methods  applied  for  testing  the  software  of  the  Tornado  Autopilot  and  Flight  Director  System.  The  over¬ 
view  of  existing  test  facilities  was  followed  by  a  detailed  presentation  of  a  new  automated  test  tool:  the  AFDS  Cross 
Software  Testing  System.  Besides  the  technical  advantages  of  this  system  like  data  recording,  reproduceability,  no  timely 
limitation,  and  permanent  actual-nominal  data  comparison  in  real  time,  the  cost  saving  aspect  also  for  future  software 
modifications  and  development  has  been  emphasized. 

Paper  41  was  prepared  by  Dr  N.J.B.Young  of  Dowty  Electronics  Ltd.  The  subject  was  “Automating  the  Testing  of 
Software”  and  provided  a  summary  of  challenging  concepts  for  practically  useful,  cost  efficient  and  automated  validation 
techniques  for  high  integrity  software.  The  paper  classified  some  available  techniques  against  a  concept  of  automatability. 
Very  soon  it  became  obvious  that  the  author’s  main  interest  was  directed  toward  the  improvement  of  methods  for  useful¬ 
ness  rather  than  for  academic  purposes.  In  this  understanding  the  results  of  detailed  studies  and  applications  of 
“automated  symbolic  executions”  were  presented  and  since  the  method  as  such  is  not  a  new  idea,  were  compared  with 
other  published  studies.  The  pragmatic  approach  of  Dowty,  characterized  by  the  question  for  a  “widely  applicable 
device”  vs  the  “perfect  device”  provides  particular  advantages  of  this  method,  and  will  be  further  completed  for  Defence 
application. 

Paper  No.42,  the  last  culmination  in  this  long  row  of  excellent,  very  professional  publications  as  presented  during 
this  symposium,  was  prepared  by  Mr  R.A.C. Smith  of  British  Aerospace,  Aircraft  Group  (Warton)  and  reported  of  “A 
Dynamic  Approach  to  Military  Avionics  Systems  Testing”.  Resulting  from  the  experience  gained  on  other  aircraft 
projects,  the  company  has  consequently  continued  in  developing  advanced  test  concepts  to  comply  with  the  requirements 
of  modem,  complex  avionic  systems.  Although  the  pre-flight  ground  test  philosophy  remains  based  on  an  integrated 
Avionics  System  development  rig,  the  techniques  presently  employed  are  marked  by  two  main  factors,  namely  the 
coverage  of  the  interaction  between  avionics  and  other  airborne  systems  by  extended  rig  facilities,  and  the  increased 
use  of  computing  for  the  data  acquisition  and  simulation  tasks,  to  the  extent  that  a  dynamic  system  testing  in  a  simulated 
flight  is  feasible.  The  dynamic  testing  technique  used  for  the  Tornado  Air  Defense  Version  was  described  in  this  paper  for 
an  example  of  actual  application  to  prove  the  aim  of  reduction  of  flying  hours  and  increase  of  effective  use  of  flight 
testing  time  available. 
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METH0DE5  DE  DEVELOPPEMENT  DU  SY5TEME 
DE  NAVIGATION  ET  O'ARMEMENT  DU  MIRAGE  2000 
D.  BONCORPS 

AVIONS  MARCEL  DASSAULT  -  BREGUET  AVIATION 
78,  Quai  Carnot  -  92214  SAINT-CLOUD 
FRANCE 


RESUME 


La  definition,  ia  nisa  au  point  at  ia  mise  an  aerie  d'un  systbme  d'arrnes  auaai  compiexe  et  intbgrb  que  ceiui  du 
MIRAGE  2000  poae  du  nombraux  problbmes.  La  presents  communication  pr-sente  lea  methodea  et  moyena  utilises  pour 
ie  developpement  du  systbma  du  MIRAGE  2000. 

Lea  methodea  aont  basbas  aur  une  etroite  collaboration  entre  iaa  Servicaa  Officials  Frangais,  iea  Irduatriais  at  iaa 
utiliaateura,  I'Armee  de  i'Air  Frangaise.  Cette  collaboration  ast  concretise  par  ia  mise  aur  pied  d*una  Coordination 
Industrielle  chargee  par  lea  Services  Techniques  d'etabiir  das  dossiars  da  travail  qui  aont  ensuite  examines  b  differents 
niveaux  par  toutes  las  partias  intbrassbes. 

Les  moyena  aont  assent iellement  beads  aur  i'utilisation  d'un  simuiateur,  d'avions  de  servitude,  d'un  banc  d'intb- -ration 
dynamique,d\jn  avion  (^integration  et  d*eviona  prototypes. 

L'asaoc iat ion  de  nouvelies  methodea  da  travail  et  de  moyena  de  developpement  sophistiqubs  parmet  d'aboutir  b  una 
definition  da  systbma  compiexe  conforme  aux  demandes  des  utiliaateura  dans  iea  meiiieurs  dbiais  et  b  moindre  coOt. 


i  -  INTRODUCTION 

Le  MIRAGE  2000  eat  bquipb  d'un  Systbme  de  Navigation  et  d*Armement  (SNA)  entibrement  numbrique.  La  piupart  des 
equipements  diaposent  de  celcuiateura  numbriques  et  diaioguent  entre  eux  par  I'intermbdiaire  cTune  liaison  numbrique 
multipiexbe  appelbe  Digibus.  L 'utilisation  de  Cette  technologic  offre  par  aiiieurs  plus  de  soupiesse  et  plus  de  capabiiitbs 
pour  U  definition  des  fonctions  opbrationneiies. 

Lea  problbmes  d'architecture  dans  la  conception  d'un  tel  systbme  aont  complexes  ,*  lea  fonctions  opbretionneiies  de  tous 
les  bquipementa  aont  hautement  intbgrbes.  Cea  reisons  ont  conduit  iea  Services  Officiels  Frengaia  et  iea  Industrials  b 
dbfinir  des  methodea  blaborbea  pour  assurer  la  definition  et  le  developpement  du  Systbme  de  Navigation  et  cfArmement 
(SNA)  du  MIRAGE  2000. 

Le  but  de  cette  communication  eat  de  dbcrire  cea  mbthodes  et  lea  moyena  utilises  dans  iea  differents  stades  de  ia 
conception,  de  l'btabliaaement  des  specifications,  de  la  realisation,  de  la  mise  au  point  et  du  passage  on  sbrie.  Nous 
n'aborderone  que  lea  aspects  libs  b  ['integration  du  SNA  et  non  pas  ceux  libs  b  un  bquipement  donnb  ou  au  iogiciei  d'un 
bqulpement  donnb  qui  peuvent  fairs  I'objet  de  communications  diffbrentea  apbcifiquea. 


2  -  MFTHOOES  OE  TRAVAIL 

Les  aystbmea  d’arrnea  des  avions  modemes  ae  caractbriaent  par  la  prbaence  I  ia  fois  de  fonctions  prop  res  b  chaque 
matbriel  et  de  fonctions  systbme  qui  intbreaaent  tous  lea  bquipementa  et  done  tous  lea  industrials.  L'idbe  de  base 
consists  done  b  fairs  travailler  cea  induatrieia  en  etroite  association  pour  la  conception  et  le  dbveloppement  du  SNA. 

Les  mbthodes  de  travail  retenues  pour  assurer  le  dbveloppement  du  Systbme  de  Navigation  et  d*Armement  du 
MIRAGE  2000  repasent  aur  la  creation  d*une  Coordination  Industrielle.  II  a'agit  d*une  equips  regroupant  dea  rep rb sen- 
tan  ts  de  1'avlonneur  -  en  l'occurance  les  AMO-BA  -  et  des  industrials  fabricents  cTbquipement*. 

Cetta  bquipe  eat  charges  de  la  realisation  (fun  certain  nombre  de  tlches  sous  contrat  dea  Services  Techniques  de  I'Etat 
et  des  reunions  rbgulibres  avec  ces  Services  Techniques  et  avec  I'Etat  Major  de  I'Armee  de  I'Air  (E.M.A.A.)  aont  prbvues 
b  tous  les  niveaux  hibrarchlques  et  aux  divers  stades  (favancement  dea  tlches  demanddes. 

L 'equips  de  coordination  a  essentlellement  pour  but  de  dbfinir  tous  les  elements  du  SNA  et  ifaider  b  la  definition  dea 
moyena  de  developpement  ndeessaires  pour  la  mise  au  point  du  SNA  sous  1 'aspect  da  I'intbgration  du  systbme  t  en  effet 
pour  assurer  toutes  les  fonctions  demarvddes  aux  systbme*  d’arrnea  modemes,  les  techniques  numdrlque*  aont  les  seules  b 
pouvoir  rdpondre  au  beaoin,  et  cela  se  traduit  par  dea  interactions  permanentea  entre  le*  different*  composants  du 
systbme.  La  erdation  de  l'dquipe  de  coordination  a  done  pour  but  de  mettre  de  fagon  permanente  en  presence  les 
diffdrents  Industrials  concemda  pour  obtenir  une  definition  cohdrente  de  1 ’ensemble  du  SNA. 

Le  marchd  da  coordination  ast  notlfld  par  le*  Service*  Techniques  b  1'avlonneur,  e'est-b-dire  les  AMO-BA  qui  cn 
ddtlennent  la  responsabilltd  et  qui  aont  chargds  de  I’anlmer  en  suacitant  tous  les  travaux  ndeessaires.  Lorsqull  y  a 
divergence  entre  les  diver*  membre*  de  la  coordination,  0*0*1 1’avlonneur  qui  eat  l'arbltra  at  c^t  son  avis  qui  prdvaut. 
Cependant  dan*  ce  damlar  cas,  11  y  a  presentation  aux  Services  Techniques  de  IF  tat  des  diffbrentea  positions  et  ce  aont 
aux  qui  p reorient  la  decision  finale. 
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2.1  T Aches  de  la  coordination 

La  coordination  a  pour  tSche  de  suivre  le  dbveloppement  du  SNA  depuis  les  premieres  definitions  initiates  jusqu’d  la 
mise  en  sbrie  de  I'avion  et  d'assurer  ia  gestion  du  programme  de  dbveloppement. 


2.1.1  Definition  initiale  du  SNA 

A  partir  d'une  fiche  programme  btablie  par  I'Etat  Major  de  1'Armbe  de  I'Air,  le  rdle  de  la  coordination  est  d'exploiter  les 
etudes  effectubes  auparavant  dans  les  domaines  interests  et  d'analyser  les  possibilites  techniques  et  technologiques  du 
moment  pour  proposer  les  principaux  objectifs  b  prendre  en  compte  pour  la  definition  du  SNA.  Ces  objectifs  sont 
discutds  avec  les  Services  Officiels  afin  de  determiner  les  hypotheses  de  base  de  la  suite  des  travaux. 


2.1.2  Definition  generate  du  SNA 

Les  tbches  de  la  coordination  consistent  alors  b  rbdiger  une  sbrie  de  documents  qui  doivent  permettre  de  dbfinir  les 
principales  fonctions  du  SNA,  les  grandes  options  sur  I'utilisation  de  I'avion  et  de  son  systbme  d'armes  ainsi  que  les 
documents  gbnbraux  de  reference  : 

.  Liste  des  fonctions  operationnelles. 

Une  premibre  definition  des  principaux  modes  de  fonctionnement  du  SNA  est  dbcrite  dans  ce  document. 

.  Architecture  materiel  le  et  iogicielle. 

Ce  document  presente  la  iiste  des  principaux  equipemer.ts  du  SNA  et  les  fonctions  qu'ils  remplissent,  ainsi 
que  ('architecture  logicielle,  c'est-b-dire  les  principes  de  repartition  des  tbches  de  calcul  entre  les 
equipements  et  la  definition  du  dialogue  entre  ces  bquipements. 

.  Analyse  logique  du  SNA. 

Ce  document  prdsente  les  principaux  modes  de  fonctionnement  des  equipements  et  du  SNA  ainsi  quo 
toutes  les  commandes  disponibles.  A  partir  de  ces  elements  il  est  defini  une  logique  systbme.  c'est-b-dire 
ies  rbgles  de  priorite  entre  modes  de  fonctionnement  des  equipements  et  modes  de  fonctionnement  du 
SNA  et  les  rbgles  d'affection  des  commandes  selon  les  modes  de  fonctionnement  des  equipements  et/ou  du 
SNA. 

.  Philosophic  des  visualisations. 

Ce  document  etablit  les  rbgles  generates  de  definition  des  visualisations  b  la  disposition  de  i'equipage,  en 
particulier  les  types  d'informations  presentees  sur  les  visualisations  cathodiques  et  les  principes  de 
repartition  entre  t6te  haute  et  t<te  basse. 

.  Philosophic  des  pannes. 

Ce  document  presente  les  rbgles  gbnbrales  qui  dictent  la  presentation  des  Informations  de  panne  b 
I'equipage. 

.  Specifications  generates  du  digibus. 

Le  systbme  de  navigation  et  d'armement  est  articuie  eutour  d'une  lieison  numbrique  multlplexbe  relient 
ies  prlnclpeux  equipements  appelbe  dlgibue.  Ce  document  precise  toutes  rbgles  generates  cfutllisetion  et 
de  couplage  eu  dlglbus  auxquelles  doivent  se  conformer  les  equipements  qui  y  sont  relies. 

.  Specifications  generates  de  msintenebilite  eu  premier  echelon. 

Ce  document  precise  les  rbgles  auxquelles  dokent  se  conformer  tous  les  equipements  afin  do  pouvoir 
disposer  d'un  systbme  coherent  au  point  de  vue  malntenabillte  et  en  perticulier  dans  le  ces  du 
MIRAGE  2000  d'evoir  une  maintenence  eu  ler  echelon  presque  totelement  intbgrbe  dens  I'avion  lui-mbme. 

.  Specifications  generates  de  meintenabiiite  au  deuxlbme  echelon. 

Ce  document  precise  les  rbgles  gbnereles  de  le  melntenance  en  atelier  et  en  particulier  pour  le 
MIRAGE  2000  le  couplage  b  un  banc  sutomatique  de  test  unique  pour  tous  les  equipements  du  SNA. 

.  Specifications  generates  des  equipements. 

Ce  document  precise  les  rbgles  gbnbreies  auxquelles  les  equipements  doivent  se  conformer  :  application 
des  normes,  conception  et  fabrication,  conditions  (fenvironnement,  essais  des  equipements  prototypes  ... 


2.1.J  Definition  dbtallieo  du  SNA 

A  partir  des  rbgles  generates  retenues  l ora  de  la  phase  precedents  du  deveioppement.  ia  coordination  a  pour  tftche  de 
rbaliser  la  definition  detainee  du  SNA,  c'est-b-dlre  aboutlr  b  la  definition  precise  des  equipements  -  materiel  et 
ioglciel  •  ainsi  que  de  leurs  Interfaces  anaioglques  et  numbrlques. 

Les  dlffbrents  documents  rbdlgbs  b  ce  niveau  sont  les  sulvants  : 

.  Specifications  globales  des  fonctions. 

Pour  cheque  mode  de  fonctionnement  du  SNA  (navigation,  conduttes  de  tlr  d'armes  air-sol  et  air-air  ...),  un 
document  dbfinlt  le  systbme  de  fag  on  globale,  c'est-b-dire  td  qu'il  est  vu  par  I'equipage  t  ce  sont  en 
particulier  les  differentes  phases  possibles  b  I’lntbrieur  d'une  f one t Ion  donnbe,  les  commandes  utllisees  et 
les  visualisations  asaocibet. 

.  Specifications  detainees  des  fonctions  operationnelles  (SDEO). 

Pour  cheque  mode  de  fonctionnement  du  SNA,  et  pour  cheque  calculates  concemb,  ce  document  dberit 
les  fonctions  b  rballser  sous  forme  de  Ioglciel  dans  un  langage  comprehensible  par  une  personne  ne 
connalssant  en  rien  Clnf ormatlque. 


-  •  r.l  ■'  ,  ■  ,  , 


.  Clauses  techniques  d'intdgration  (CTI)  des  dquipements. 

Pour  tous  les  dquipements  du  SNA,  ce  document  presents  la  definition  du  materiel,  sos  fonctions,  ses 
interfaces  avec  le  reste  du  SNA,  ses  conditions  d’installation  dans  I'avion,  sa  mise  en  oeuvre,  sa  fiabilite  et 
ses  performances. 

.  Fiches  d'interfaces  analogiques. 

Ce  document  regroupe  la  definition  detailiee  de  toutes  les  liaisons  analogiques  du  SNA  une  par  une  : 
nature  de  la  liaison,  dquipements  emetteur  et  rdcepteur,  outils  d'entrde  et  de  sortie,  type  de  cfiblage  ... 

.  Fiches  d'interfaces  numdriques. 

Ce  document  est  certainement  le  plus  important  et  le  plus  representatif  de  tous  les  travaux  d'integration 
du  SNA.  II  ddfinit  en  effet  en  detail  toutes  les  informations  echangees  sous  forme  numdrique  entre  les 
dquipements,  c'est-4-dire  la  grande  majorite  d'entre  elles  :  nom  de  I'information,  equipement  emetteur, 
equipement(s)  rdcepteuKs),  frequence  de  transmission,  nombre  de  bits  representatif,  definition  du  LSB, 
resolution  ... 

.  Synoptiques  de  cdblage. 

Ces  synoptiques  reprdsentent  I'ensemble  des  liaisons  entre  equipements  du  SNA  en  precisant  notamment 
les  types  de  prise  et  les  brochages  de  cheque  prise.  Us  permettent  d'etablir  les  schemas  et  les  liasses  de 
realisation  des  cdblages  de  I'avion. 


Rdgartition  des  fonctiong  mat  dr  i  elles  etjogicielles. 

Les  fonctions  rdalisdes  par  les  dquipements  peuvent  fitre  rdparties  en  deux  categories  : 

.  Les  fonctions  autonomes. 

Ce  sont  les  fonctions  rdalisdes  sous  forme  materielle  et/ou  logicielle  et  qui  ne  dependent  pas 
d'informations  dlabordes  par  d’autres  dquipements.  Dans  ce  cas  seules  les  clauses  techniques  d'intdgration 
(CTI)  et  les  fiches  interfaces  ddfinissent  de  telles  fonctions  rdalisdes  par  un  equipement  uonnd.  C'est  par 
exemple  le  cas  de  toutes  les  fonctions  capteur  rdalisdes  dans  une  centrale  adrodynamique  ou  dans  une 
centrale  4  inertie. 

.  Les  fonctions  intdgrdes. 

Ce  sont  les  fonctions  qui  dependent  d'informations  dlabordes  par  d'autres  dquipements.,  Ce  sont  par 
definition  les  fonctions  opdrationnelles  du  SNA,  celles  qui  font  1'objet  de  plus  de  probldmes  de  mise  au 
point  et  de  vp Vjation  et  qui  doivent  bdndf icier  de  la  souplesse  offerte  par  le  logiciel.  Files  se  truuvent 
done  fitre  toujuurs  rdalisdes  sous  forme  logicielle  et  sont  ddfinies  par  les  specifications  ddtailldes  des 
fonctions  opdrationnelles  de  I'dquipement  donnd  et  par  les  fiches  interfaces. 


C'est  au  niveau  de  detail  des  CTI,  des  SDFO  et  des  fiches  interfaces  que  s'arrdtent  les  tfiches  de  la  coordination  t  c'est 
en  effet  la  concrdtisation  au  niveau  de  cheque  equipement  des  analyses  gdndrales  d'intdgration  et  de  la  repartition  entre 
les  dquipements  des  diffdrentes  fonctions  &  rdaliser  pour  assurer  le  bon  fonctionnement  du  SNA.  Les  travaux 
consdcutlfs  -  le  cholx  des  composants,  la  ddfinltion  intdrieure  de  I'dquipement,  la  rdalisation  du  logiciel  -  ne  sont  plus  du 
ressort  de  la  coordination  mais  de  I'dquipementier  lui-mdme. 


2.1.4  Mise  eu  point  du  SNA 

La  coordination  assure  le  suivi  de  la  mise  au  point  du  SNA  sur  les  ditfdrents  moyens  de  ddveloppement  prdvus.  Cette 
mise  eu  point  se  tredult  par  de  nombreuses  modifications  eussi  blen  matdrielles  que  loglcielles  par  rapport  4  le 
ddfinltion  de  rdfdronce  du  syst&me  ddcrite  dans  les  documents  CTI,  SDFO  et  fiches  Interfaces.  De  fagon  4  dtre  en 
mesure  (^identifier  4  tout  instant  la  ddfinltion  prdcise  et  compldte  du  SNA,  il  est  ndeessaire  de  mettre  sur  pied  des 
proeddures  trds  rigoureuaes  auxquelles  tous  les  industriels  concernds  doivent  se  conformer.  Toute  modification,  aussi 
mlnime  solt-elle,  par  rapport  aux  documents  de  rdfdrence  doit  done  faire  I'objet  d*une  fiche  d*dvolutlon.  Les  fiches 
devolution  sont  rddlgdes  solt  par  des  membres  de  I'dqulpe  de  coordination  soit  par  des  membres  des  dquipes  de  mise  eu 
point ;  mais  elles  doivent  avoir  I'occord  de  la  coordination  event  toute  diffusion  pour  dtude  ou  application  de  fagon  4 
s’assurer  que  les  modifications  demanddes  ne  remettent  pas  en  cause  les  prlnclpes  retenus  eu  ddbut  du  programme  de 
ddveloppement  et  la  cohdrence  d'ensemble  du  SNA  et  que  par  ailleurs  elles  n’ont  pas  de  consdquences  Inattendues  sur 
d'autres  dquipements  ou  d'autres  fonctions. 

Pendant  la  phase  de  ddveloppement  et  par  le  jeu  de  (’application  successive  des  fiches  devolution,  on  se  retrouve 
toujours  dans  la  situation  ou  il  exlste  plusieurs  versions  de  ioglclel  pour  un  mdme  dqulpement  et/ou  des  modifications  de 
dblage  appllqudes  sur  un  mo  yen  de  ddveloppement  et  pas  encore  sur  un  autre.  C'est  dgalement  une  des  tlches  de  la 
coordination  de  tenlr  4  jour  la  ddfinltion  prdcise  des  dlffdrents  dquipements  et  moyens  de  ddveloppements  utlllsds  pour 
la  nun  au  point  du  SNA,  da  ddfinrr  lea  tontrsihies  de  VimuHindta  d1  application  de  cans  mbs  ticnes  (fivonAion  ainai  quo 
les  dtats  de  compatibilitds  entre  diverses  versions  de  matdriels  et/ou  logiciel. 


2.1.5  Sdrle 

Lorsque  I'avion  est  en  sdrle,  il  s'agit  dMtablir  avec  prdcision  la  ddfinltion  aussi  bien  matdrielle  que  logicielle  des 
squ.pertiems  du  SNA  .it'mujhJ  U  est  une  wtite  carattdrfsam  i  or.  sxaos  de  oelmititm  norme  it  syaieine  thumbs 
de  I’avion.  La  ddfinltion  du  standard  est  caractdrisd  par  i 

.  in  descriptlf  exhaust  If  des  capabllltds  opdrationnelles  de  I'avion, 

.  une  lists  des  rdfdrences  de  tous  les  dquipements, 

.  une  llste  des  caractdrlstlques  de  I’avion  capable  cfeccuellllr  ces  dquipaments. 
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Par  ailleurs  la  rfiffirencs  d'un  fiquipement  est  constitute  par  juxtaposition  du  type  et  de  I'ttat  de  1'fiquipement.  Le  type 
sort  &  identifier  la  fonction  opfirationnelle  de  l'tquipement  et  ne  prend  en  compte  que  les  seuls  critferes  d'interchangea- 

UUJ  k>  6t  idkn  I  Uh>iW  J*  Ijf-jr  (Wat  kyjt  v  .if#  'iti'iyiuiiwi'  At  ,<i  *  »  I 

interchangeabilitfis  mficanique,  filectrique,  optrationnelle  ou  de  maintenance  ler  tchelon.  La  notion  d'ttat  n'intervient 
que  pour  les  fiquipements  complexes  comportant  plusieurs  sous  ensembles  pouvant  Stre  changes  au  2feme  tchelon.  Les 

,SW/(!cnT4(acjr.ilB.*t«i»d<  cn*  msaiu  ..lUnt  k  n  wt  dca  Wutiyt  *,.*  .rttln?  v'.ysdMWt4 

II  appartient  h  la  coordination  de  dtfinir  les  difftrents  standards  et  les  grilles  de  compatibilities  types/standards 
correspondantes  en  fonction  des  object ifs  calendaires  fixts  par  les  utilisateurs. 

4.  .-tpjjj  -lur*  >  4m  -  VuS  fc*.  do  I?  ^  <>NA  «-»  Ou-  wr  Jil  irfnienirT.,  ta 

documentation,  les  moyens  de  formation  au  sol  des  personnels  de  l'Armte  de  l'Air,  la  definition  d’un  nouveau  standard 
n'a  lieu  qu'fi  une  frequence  au  plus  tgale  &  l'annte  et  les  procedures  d'approbation  et  d'application  sont  plus  complexes  et 
i  Jus  Ionises  que  endant  la  jhase  de  ipem-in*-  oft  *ea  W*  dpiwnf  ,‘ltv  ^  jli  l.-ftd  pvh  idNPiMtf. 


2.1.6  Gestion  du  programme 

Pendant  toute  la  phase  de  dtveloppement  du  SNA,  la  coordination  a  pour  tfiche  de  fend  la  gestion  d'ensemble  du 
programme.  Cette  gestion  consiste  4  definir  en  debut  de  programme  les  moyens  de  developpement  et  les  besoins  en 
eqwpemetlte  tuHTSf-jporidmAi  ei  tnHlWt  &  BSMi-tT  te  eoft-i  T  -gUu,ei  do  ptefi  t&ef K  itqdt.  U  fhfitfibde 

PERT  est  utilisee  et  la  coordination  a  defini  1'ensemble  des  sous  reseaux  regroupant  toutes  les  phases  du  developpement. 
La  nr  -se  £  jour  du  rdseau  complet  a  lieu  tous  les  trois  mois  au  cours  d'une  reunion  avec  toutes  les  parties  int<§ress6es 
,aKjv  Htn.id-diilw.iwit  U*i  ii«yo*Uiam  r.iedrt&wi*  w  Je  t-tir  is 


2.2  Eonctionnement  de  la  coordination 


Le  fonctionnement  de  la  coordination  met  en  oeuvre  plusieurs  types  d'organisation  du  travail  selon  les  sujets  h  traiter. 
Par  ailleurs  les  tfiches  &  rdaliser  s'intfegrent  dans  deux  schemas  diff6rents. 


2.2.1  Organisation  des  travaux 

L'equipe  de  coordination  se  compose  d'un  certain  nombre  de  representants  de  tous  les  industriels  concern6s,  travaillant 
en  permanence  en  liaison  6troite  entre  eux  sur  les  diverses  tfiches  de  la  coordination.  Si  l'etude  d'un  sujet  particulier 
dt  It  appt'  l  tfei  On  erfct  -oft  yrunpt  de  aft  SrertgS  CjLrr  fiyeef  tff  3% '  1  lenrt  4eS  tn  »  ja»  petal*!* 

au  sujet  donn4.  Certains  groupes  de  travail  peuvent  ne  comprendre  qu'un  nombre  Iimit6  d'industriels  en  fonction  du  sujet 
concerne.  C'est  ainsi  qu'ont  ete  erdds  les  groupes  de  travail  architecture,  air-air,  maintenance,  contre-mesures. 


2.2.2  Types  de  tfiches 

Deux  types  de  tfichas  ont  dtd  identifies.  Les  tfiches  courantes  sont  les  tfiches  de  fond  de  la  coordination  fivalufies  de 
fagon  forfaitaire  et  qui  doivent  mener  6  la  realisation  de  tous  les  documents  cites  au  §  2.1.  Les  tfiches  ponctuelles 
correspondent  6  des  etudes  bieri  precises  dont  le  besoin  apparaft  au  fur  et  fi  mesure  de  l'avancement  des  tfiches 
courantet.  La  coordination  fait  alors  aux  Services  Techniques  une  proposition  technique  et  financifire  d'une  etude 
ponctuella  dont  le  contenu,  l'objactif  et  l'aboutissement  sont  clairement  identifies. 


2.3  Liaisons  avec  les  Services  Officiels 


Le  principe  de  base  de  fonctionnement  de  la  coordination  consiste  fi  la  realisation  par  celle-ci  des  difffirents  documents 
correspondent  aux  phases  successivas  du  developpement  citees  ci-dessus.  Lorsque  la  coordination  a  realise  un  document 
de  definition,  celui-ci  est  transmis  aux  Servicas  Techniques  et  &  1'Armee  de  l'Air  pour  examen.  Des  reunions  sont  alors 
organisfies  entre  la  coordination  et  les  Services  Officiels  pour  la  discussion  du  document,  pour  fournir  les  explications 
complfimentaires  demandfies  et  aboutir  &  la  definition  qui  agree  toutes  les  parties  interessees.  La  coordination  diffuse 
alors  le  document  ddfinitif  qui  deviant  la  reference. 

Pour  assurer  ce  processus  de  travail  general,  un  certain  nombre  da  rancontres  particulifires  viennent  ponctuer  le  travail 
de  la  coordination  afin  d'assurer  une  liaison  etroite  et  rfiguliftre  avec  les  Services  Officiels. 


2.3.1  Point  coordination 

Le  point  coordination  est  une  reunion  qui  a  lieu  toutes  les  trois  semaines  entre  l'equipe  de  coordination  et  les  Servicas 
Techniques.  Cette  reunion  a  pour  but  de  faire  le  bilan  des  reunions  passfies,  de  falra  un  bref  resume  de  leur  contenu 
ainsi  que  de  definir  et  d'organiser  toutes  les  reunions  &  venir.  Toutes  les  reunions  sont  citees,  qu'alles  aient  lieu 
seulement  entre  Industriels,  antre  Industrials  et  Services  Techniques  ou  antre  Industriels,  Services  Techniques  at 
I'Armee  de  l’Air.  Au  point  coordination  sont  figalement  et  rapldement  abordes  l'avancement  das  travaux  des  difffirents 
groupes  de  travail  et  ies  points  divers  susceptlbles  dSntfirasser  les  participants. 


2.3.2  Avancement  semestrlel 


Tous  les  six  mois,  une  reunion  avec  les  plus  hautes  sutoritfis  du  programme  MIRAGE  2000  des  Services  Techniques  et  de 
l'E.M.A.A.  fait  un  point  de  l'avancement  gfinfira1  des  travaux  depuis  la  reunion  prfiefidente  :  les  travaux  de  la 
coordination  et  les  essais  sur  les  divers  moyens  de  dfiveloppement. 


-■far'-"4*  • 
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2.3.3  Reunions  techniques  particuliferes 

A  chaque  fois  qua  la  coordination  le  juge  ndcessaire  pour  la  bonne  suite  de  ses  travaux,  elle  demande  une  reunion 
technique  sur  un  sujet  particulier  avuc  les  Services  Techniques  et  si  n^cessaire,  selon  le  sujet,  avec  I'Armee  de  I'Air. 


Par  ailleurs,  chaque  groupe  de  travail  a  des  reunions  rdgulieres  entre  industriels  et  p£riodiquement  les  Services 
Techniques  sont  invites  6  I'une  de  ces  reunions  pour  faire  un  point  precis  des  travaux  en  cours. 


2.3.4  Reunions  d'aoprobation  des  fiches  devolution 


Toutes  les  fiches  devolution  diffuses  par  la  coordination  font  I'objet  de  reunions  p6riodiques  avec  les  Services 
Techniques  et  1*E.M.A.A.  pour  decider  de  leur  acceptation  et  des  conditions  d'applicatron  dans  les  divers  dquipements. 
Les  reunions  ont  lieu  4  plus  grande  frequence  lors  de  la  phase  de  developpement  (de  1'ordre  de  2  mois)  qu'apr^s  la  mise 
en  sdrie  de  I'avion  (de  1'ordre  de  4  mois). 


2.3.5  Eoumitures  contractuelles 

Compte-tenu  des  aldas  de  definition  et  des  divers  paramdtres  4  prendre  en  compte,  la  plupart  des  documents  que  doit 
foumir  la  coordination  ne  font  pas  I'objet  de  dates  contractuelles  de  diffusion.  Les  sejles  fournitures  contractuelles  de 
la  coordination  sont  les  suivantes  : 

.  La  mise  6  jour  du  planning  de  developpement  technique  du  programme  sous  forme  PERT  tous  les  trois 
mois. 

.  Un  document  faisant  le  point  de  l'avancement  des  travaux  de  la  coordination  tous  les  six  mois  :  it  s'agit  en 
fait  du  compte-rendu  de  la  reunion  d'avancement  semestriel. 

.  Un  document  pour  chaque  groupe  de  travail  faisant  le  point  de  l'avancement  des  travaux  de  ce  groupe  tous 
les  six  mois  :  dans  ce  document  figurent  en  particulier  les  compte-rendus  de  toutes  les  reunions  du  groupe. 

.  Les  dossiers  d'dtude  pour  chaque  etude  ponctueile  qu'il  a  ete  juge  ndcessaire  d'effectuer. 


2.4  Bilan  de  la  coordination 

L'expdrience  acquise  4  ce  jour  a  montrd  que  l'organisation  de  la  coordination  industrielle  rdpondait  bien  aux  objectifs 
fixes.  Les  liaisons  etroites  que  les  industriels  ont  ete  tenus  d'entretenir  entre  eux  pour  la  definition  de  1'ensemble  du 
systdme  de  navigation  et  d'armement  ont  permis  d'aboutir  4  un  systfeme  efficace  et  coherent.  Mais  il  est  egalement 
apparu  que  le  rflle  des  AMD-BA  en  tant  que  responsable  et  animateur  de  la  coordination  etait  essentiel.  En  effet  il  est 
souvent  arrive,  et  ceci  est  parfaitement  normal  et  nature),  que  tel  ou  tel  industriel  ait  tendance  4  proposer  des  solutions 
qui  avaient  des  avantages  pour  ses  dquipements  mais  qui  presentaient  par  contre  des  inconvenients  pour  1'ensemble  du 
SNA.  C'est  alors  que  les  AMD-BA  intervenaient  en  tant  qu'arbitre  neutre  puisque  ne  fabricant  aucun  equipement  et 
ayant  pour  seul  objectif  de  ddfinir  un  syst4me  coherent  et  homogfene.  C'est  ainsi  que  ce  sont  plus  particulidrement  les 
*  AMD-BA  qui  ont  redige,  avec  I'accord  des  autres  cooperants  bien  entendu,  tous  les  documents  de  specifications 

generales  du  SNA  :  specifications  generates  des  equlpements,  specifications  generales  du  digibus,  specifications 
generales  de  maintenance,  philosophic  des  commandes  et  des  visualisations,  philosophie  des  pannes  ... 


3  -  MOYENS  DE  DEVELOPPEMENT 

Les  syst4mes  de  navigation  et  d'armement  modernes  se  caracterisent  essentiellement  par  leur  haut  niveau  d'integration 
dans  les  differents  equipements  constltuant  le  SNA  et  par  la  banalisation  des  commandes  et  visualisations,  ceci  grSce  4 
l'utillsation  de  calculateurs  numeriques  et  tin  visualisations  cathodiques.  La  mise  au  point  d'un  syst4me  d'armes 
complexe  dolt  done  utiliser  des  moyens  de  developpement  capablcs  de  trsiter  d'une  part  ies  probl4mes  de  logiciel  et 
d'autre  part  les  probl4mes  d'ergonomle.  L'analyse  a  montrd  que  de  tels  moyens  doivent  §tre  assez  complets  pour 
permettre  une  investigation  eussl  exheustive  que  possib's  des  loglclels  temps  rdel,  et  assez  souples  pour  s'adapter  tr4s 
rapldement  aux  demandes  des  pllotes  dvaluateurs.  Par  ailleurs  il  est  apparu  que  de  nombreuses  phases  d'essais  pouvaient 
se  felre  au  sol  et  qu'il  n’etalt  pas  possible  de  monter  des  installations  d’essais  complexes  sur  I'avion  d'armes  lui-m6me. 

Ces  diverses  considerations  nous  ont  conduit  4  ddfinlr  differents  moyens  de  developpement  permettant  la  mise  au  point 
depuls  ('installation  laboretolre  au  sol  jurqu'4  l'evlon  prototype  lul-mSme  avec  un  enchatnement  logique  dans  les  phases 
successlves  de  la  validation  d'un  systems  crarmes. 


3.1  Svsteme  d'anlmation  vlsuallsatic 


3.1.1  Definition 

Ce  systems  se  compose  d'un  manche,  d'une  manette  de  gaz,  d'un  clavier  avec  de  nombreux  interrupteurs  pour  simuler 
les  commandes  et  d'un  ecran  cethodlque  polychrome  pour  vlsuallser  t<te  haute  et  tdte  basse.  Ce  simulateur  dispose  d'un 
modeie  avion,  travaille  en  temps  reel,  et  est  mis  en  oeuvre  par  les  AMD-BA  qui  assurent  en  outre  toute  la 
programmation  ndeessaire. 
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3.1.2  Rflle 

Ce  systdme  a  pour  but  de  permettre  urte  premiere  etude  des  visualisations  correspondent  k  un  mode  de  fonctionnement 
du  SNA.  11  permet  de  ddfinir  las  formes  de  reticules,  la  necessite  de  certaines  informations,  la  repartition  entre  tate 
haute  et  tSte  basse.  C'est  k  partir  de  cette  premi&re  preetude  que  peuvent  6tre  flcrites  les  specifications  globales  des 
fonctions  du  SNA. 


3.2  Simulateur  d'etude 


3.2.1  Definition 

Le  simulateur  d'etude  est  une  cebine  de  pilotage  montee  sur  une  plate-forme  6  axes.  Un  systbme  de  visualisation  permet 
de  representer  le  sol,  soit  un  aerodrome  et  ses  environs  pour  la  simulation  de  i'approche,  soit  un  terrain  reel  pour  le 
simulation  de  la  navigation  basse  altitude.  La  cabine  est  equipee  des  equipements  de  pilotage,  des  visualisations 
cathodiques  tflte  haute  et  tflte  basse  et  des  principals  commandes  nflcessa'res  pour  la  mise  en  oeuvre  du  SNA. 

Ce  simulateur  est  mis  en  oeuvre  par  un  Service  de  ITtat,  ie  Centre  dTssais  en  Vol  (C.E.V.)  mais  le  logiciel  du 
simulateur  est  realise  pour  la  plus  grande  partie  par  les  industriels  de  la  coordination  garants  de  la  coherence  des 
logiciels  de  simulation  et  de  la  definition  de  base  du  SNA.  Les  documents  de  reference  pour  ce  simulateur  sont  les 
specifications  globales  des  fonctions  du  SNA. 


3.2.2  ROle 

Le  simulateur  d'etude  a  pour  but  d'etudier  l'aspect  ergonomique  du  SNA,  c'est-b-dire  les  commandes  et  visualisations 
associees  aux  differents  modes  de  fonctionnement  du  SNA.  Les  essais  se  font  dans  un  environnement  representatif  avec 
une  simulation  en  temps  r6ei  de  toua  les  elements  mis  £  la  disposition  du  pilote. 

Divers  pilotes  evaluateurs  volent  sur  ce  simuiateur,  formulent  toutes  leurs  remarques  et  proposent  des  modifications 
par  rapport  aux  definitions  "papier"  £  partir  desquelles  ii  est  toujours  difficile  de  juger  ce  que  vont  representer  en 
dynamique  des  visualisations  donnees. 

Pour  que  ce  simulateur  ait  un  rflle  utiie  dans  ie  programme  de  developpement,  il  faut  bien  sur  que  les  essais  devaluation 
aient  lieu  assez  tflt  pour  en  tirer  les  consequences  et  les  appliquer  au  cours  de  la  realisation  des  logiciels  des 
equipements  embarqufls. 


3.3  Banc  de  generation  fliectrioue 

3.3.1  Definition 

Ce  banc  se  trouve  en  laboratoire  et  est  reprflsentatif  de  la  veritable  generation  fllectrique  de  1'avion  :  alternateurs, 
transfo  redresseurs,  batterie,  cflblages.  Ce  banc  est  mis  en  oeuvre  par  les  AMD-BA. 


3.3.2  Rflle 

Le  but  de  ce  bene  est  de  verifier  le  fonctionnement  correct  de  la  generation  eiectrique  en  presence  d'un  puis  de 
plusieurs,  enfin  de  tous  les  equipements  qui  y  sont  connectes.  11  y  est  en  particuiier  etudie  toutes  les  consequences  sur 
les  nlveaux  de  tension  alternative  et  continue  de  la  mise  en  marche  et  de  ia  coupure  des  equipements  du  SNA.  Les  biians 
de  consommation  de  chaque  equipement  selon  leurs  modes  de  fonctionnement  sont  dgelement  mesurds  sur  ce  banc. 


3.6  Ay  ions  de  servitudes 

Plusieurs  a v Ions  de  servitude  specialises  sont  mis  en  oeuvre  par  le  Centre  d "Essais  en  Vol.  11s  n'ont  pas  pour  but  de 
contrlbuer  k  Is  mise  au  point  du  systfcme  d'ermes  Intflgre  meis  k  ceiie  des  equipements  complexes  du  SNA.  En  effet  les 
essais  d'integration  ne  sont  censes  ddbuter  que  lorsque  les  equipements  eux-mflmes  sont  au  point.  Les  avions  de 
servitude  sulvants  ont  elnsl  partlcipd  au  programme  MIRAGE  2000  s  un  evion  pour  le  rader,  un  evion  pour  les  systbmes 
de  contremesures,  un  avion  pour  ie  coupiage  du  rader  k  l'eutodirecteur  du  misslie  air-air. 


3.5  Bene  d'integration 


3.5.1  Definition 

Le  banc  d'integration  mis  en  oeuvre  en  iaboretolre  par  les  AMD-BA  est  ie  piece  maftresse  de  {'integration  du  systfeme 
d'ermes.  II  a  pour  but  cfaisurer  ie  bon  fonctionnement  de  tous  les  equipements  du  SNA  relies  entre  eux  comme  sur  avion 
et  d*obtenlr  une  optlmisetlon  des  performences  globaies  du  systbme.  Pour  attelndre  cet  objectif,  le  systbme  peut  fltre 
excite  de  deux  fagons  compiementalres  i 

.  statique  :  c’est  ia  simulation 

.  dynamique  s  c’est  la  stimulation,  methods  originate  mise  au  point  par  les  AMD-BA  et  utillsde  sur 
differents  programmes  depuis  1975. 


r 


AW 
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Le  banc  d'intdgration  se  compose  de  different*  elements  : 

-  Des  bates  comportant  :  .  les  dquipements  reels  de  l'avion  relids  par  un  cflblage  type  avion. 

.  la  generation  dlectrique  de  l'avion  excitde  par  une  generation  dlectrique  de  laboratoire. 

.  des  simulateurs  analogiques  et  digitaux  pouvant  se  substituer  b  des  dquipements  rdels. 

.  des  simulateurs  d'armements. 

.  divers  moyens  de  surveillance  et  appareils  de  mesure. 

-  Des  moyens  extdrieurs  de  mise  en  oeuvre:  .  des  terrasses  permettant  ('installation  de  radars  et/ou  de  missiles 

avec  possibility  d'dmission  radar. 

.  des  baies  de  test  ou  de  mise  en  oeuvre  des  principaux  dquipements  du 
SNA  :  radar,  calculateurs,  centrale  b  inertie  ... 

.  un  support  harmonisable  de  centrale  &  inertie. 


3.5.2  Essais  statigues 


3.5.2.1Nature  des  essais  statigues 


Ces  essais  consistent  b  mettre  le  systbme  complet  sous  tension  et  b  contrfller  le  bon  fonctionnement  de  1'ensemble  dans 
un  certain  nombre  de  configurations  statiques  du  SNA.  11s  permettent  ainsi  de  procdder  aux  operations  de  mise  au  point 
suivantes  : 


.  Adaptation  et  performances  des  interfaces  matdriel. 

.  Sensibility  du  systbme  aux  coupures  et  variations  de  la  generation  eiectrique. 

.  Performances  des  detecteurs  :  centrale  b  inertie,  centrale  aerodynamique. 

.  Contrflle  des  precisions  des  parambtres  de  sortie  du  systbme  sur  les  organes  de  visualisations. 

.  Contrflle  des  logiques  de  commande  et  de  pannes. 

.  Correction  des  erreurs  de  logiciel  dues  b  des  errsurs  de  programmation  ou  b  des  defauts  de  principe. 


3. 5. 2. 2 Limitations  des  essais  statigues 


De  part  leur  nature,  ces  essais  sont  limites.  Seuls  en  effet  sont  traites  les  problbmes  d'interfaces  materials  et  les 
problbmes  de  logique  sur  un  nombre  ndcessairement  restreint  d'echantillons.  Par  ailleurs  tous  les  problbmes  libs  b  la 
dynamique,  tels  que  filtrage,  extrapolation,  bruit,  precision  dynamique  ...  d'autant  plus  importants  que  les  fonctions  sont 
reparties  dans  differents  calculateurs  numdriques  relies  par  une  liaison  numdrique  multiplexde,  ne  peuvent  fltre  traitds  b 
ce  stade. 


Us  ne  pourraient  fltre  traitds  qu'en  vol.  Or  1'analyse  et  le  resolution  des  problbmes  rencontrds  en  vol  sont  trbs  difficiles  : 

.  Limitation  en  volume  de  ('installation  d’essais  embarqude. 

.  Difficulty  d'enregistrer  b  priori  les  bons  parambtres. 

.  Interpretation  difficile  pour  le  pilote  d'un  phdnombne  anormal  survenu  en  vol. 

.  Difficulty  de  se  remettre  dans  le  mime  configuration  de  vol. 

.  Ndcessitd  de  voler  b  nouveau  pour  tester  une  modification. 


Essais  dynamic 


Pour  rdsoudre  les  problbrr.es  evoquds  ci-dessus,  les  AMD-BA  ont  ddveloppd  une  mdthode  qui  a  connu  ses  premibres 
applications  dbs  1975  sur  le  progremme  Super  Etendard.  Cette  mdthode  utilise  le  banc  d'intdgretlon  precddemment 
ddcrlt  couple  b  un  ordlnateur  pour  stlmuler  le  systbme  d'armes.  La  stimulation  consiste  b  remplacer  tout  ou  partie  des 
ddtecteurs  par  leurs  simulations  afln  de  gdndrer  des  parambtres  cohdrents  dynamiquement  (comme  en  vol)  b  1'entrde  du 
systbme  et  b  entrer  dans  le  systbme  rdel  le  plus  en  amont  possible  evec  des  parambtres  physiques  primalres  -les 
Informations  sont  alors  en  nombre  Umitd  -  et  non  b  des  nlveeux  intermddlalres  -  ou  les  parambtres  peuvent  Stre  en 
nombre  llllmite. 


La  stimulation  fonctlonne  b  partlr  de  bandes  comportant  tous  les  parambtres  prlmaires  ndcessalres  enregistrds  de  fagon 
cohd  rente.  Les  bandes  peuvent  Stre  soit  des  bandes  entlbrement  synthdtlques,  soit  des  bandes  Issues  d'un  slmulateur  de 
vol,  soit  des  bandes  provenant  d’enregistrement  en  vol  sur  un  autre  avion  ou  sur  l'avion  d'essai  lul-mdme.  L 'ordlnateur 
tralte  ces  dorados  de  fagon  b  foumlr  au  banc  ^integration  les  Informations  correspondant  exectement  au  niveau 
physique  ou  s'est  fait  I’enregistrement,  c'est-b-dlre  en  gdndral  entre  les  ddtecteurs  et  les  organes  de  gestlon  et  de 
celcul.  Les  demlers  sont  done  excltds  par  des  parambtres  dvoluent  en  temps  rdel  de  fegon  dynamique  et  cohd  rente, 
f  one  Dormant  comme  sur  avion  en  fonction  des  commandos  et  gdnbrent  les  informations  correspondantes  sur  les  organes 
rdels  de  visualisations. 


La  stimulation  per  met  de  faire  toute  la  mise  au  point  dynamique  du  systbme  in it  internment  de  l'avion,  done  de  fagon 
plus  raplde  et  plus  dconomlque.  Elle  permet  dgalement  de  comprendre  les  problbmes  survenus  en  vol  en  rejouant  eu  sol 
autant  de  fois  qu’U  le  faut  la  phase  critique  et  en  enregistrant  tous  les  parembtres  dlsponlbles  (blen  plus  nombreux  que 
sur  avion). 
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Elle  permet  ensuite  de  valider  les  modifications  proposees  avec  le  mfime  profil  de  vol  avant  de  faire  un  nouveau  vol. 
Elle  permet  enfin  de  localiser  avec  precision  1'equipement  en  cause  lorsqu'une  anomalie  est  survenue,  ce  qui  est  toujours 
difficile  dans  un  systbme  hautement  intdgre. 


3.5.4  Rflle  du  banc  d'inteqration 

Le  banc  d'integration  est  le  lieu  de  passage  obligatoire  de  tout  dquipement  et  de  toute  version  de  logiciel.  II  existe  une 
r&gle  bien  precise  &  laquelle  il  n'est  accepts  aucune  exception  :  tout  6quipement  ou  toute  version  de  logiciel  d'un 
equipement  ne  peuvent  Stre  months  sur  un  avion  quelconque  qu'apres  avoir  6te  valid6s  auparavant  au  banc  d'integration. 

Le  banc  d'integration  stimulabie  intervient  6  quatre  niveaux  differents  lors  du  d6veloppement  d'un  systbme  : 

.  Mise  au  point  et  validation  d'une  premiere  definition  de  materiel  et  de  logiciel  avant  vol. 

.  Etude  des  anomalies  rencontres  en  vol. 

.  Validation  des  modifications  integrees  dans  les  equipements  avant  nouveau  vol. 

.  Validation  des  standards  de  serie  avant  livraison  des  materiels  et  logiciels  h  la  chatne  de  production. 


3.6  Avion  d'inteqration 


J.6.1  Definition 

L'avion  d'integration  est  un  MYSTERE/FALCON  XX  dont  le  poste  pilote  gauche  est  inchange  mais  dont  le  poste  pilote 
droit  est  amenagd  comma  le  poste  pilote  de  (’avion  d'armes.  Dans  la  cabine,  des  armoires  contiennent  les  equipements 
du  SNA  et  une  installation  d'essais.  Un  poste  d'ingenieur  d'essais  est  prevu  avec  recopie  des  visualisations  principales  du 
poste  pilote  droit  et  accfes  &  certaines  commandes  de  ('installation  d'essais  et  aux  simulateurs  d'emport. 

Le  SNA  de  ('avion  d'armes  est  complet  &  ('exception  du  pilote  automatique  et  des  contre-mesures.  Tous  les  armements 
possibles  de  ('avion  d'armes  sont  simulds  par  des  tiroirs  sp6cifiques  avec  des  commandes  h  la  disposition  de  I'ing6nieur 
d'essais. 


3.6.2  Rflle 

Le  r8le  de  ('avion  d'integration  est  de  permettre  une  premiere  validation  en  vol  du  systems  d'armes  avec  le  double 
avantage  sulvant  :  coOt  inf6rieur  &  ('avion  d'armes  lui-mSme  et  possibility  d'analyse  en  vol  plus  fine  grSce  h  la  presence 
k  bard  de  plusleurs  personnes.  Cet  avion  permet  egalement  une  premiere  evaluation  des  diff6rentes  fonctions 
op6rationnelles  par  les  utilisateurs  &  moindre  coOt. 


3.7  Maquette  radio-eiectrioue 

La  maquette  radio-eiectrique  est  un  avion  complet  e  l'echeile  1/1  6quip6  de  fag  on  representative  avec  tout  ce  qui  peut 
avoir  des  influences  radlo-eiectriques  :  generation  eiectrique,  cfiblages,  structure  metallique  principaie,  antennes, 
equipements. 

Cette  maquette  permet  d'6vaiuer  les  consequences  radio-eiectriques  du  fonctionnement  normal  du  SNA  :  perturbations 
dues  6  la  generation  eiectrique,  influences  des  emissions  sur  les  equipements  et  les  emports,  diagrammes  d'antennes  ... 


3.8  Chambre  an6choTde 

Le  chambre  anecholde  est  capable  de  contenlr  un  avion  d'armes  6quipe  et  permet  en  particular  de  mesuror  1'infiuence 
reciproquo  des  materiels  de  contre-mesures  et  leur  influence  sur  tous  les  autres  equipements  dlectronlques  et  emports 
possibles  de  l'avion.  C'est  8  partlr  des  essals  effectuds  en  chambre  andchoTde  que  sont  ddflnis  les  elements  permettant 
de  ddflnir  les  regies  de  compatibilite  entre  tous  les  equipements  de  i'avlon. 


3.9  Avlons  prototypes 

Les  avions  prototypes  forment  le  demier  element  de  la  chatne  sequentielle  des  moyens  de  developpement.  C.  tains 
prototypes  sont  consacrds  h  la  mise  au  point  de  l'avion  iui-m6me  •  le  moteur,  les  commandes  de  vol,  les  systkmes 
hydraulique,  eiectrique  et  carburant  -  et/ou  aux  aeules  ouvertures  de  domaines  des  emports  envisages :  11s  ne 
component  done  pas  tous  les  equipements  du  SNA.  Par  centre  ceux  qut  sont  destines  8  ia  mise  au  point  du  systems 
d'armes  sont  equipds  de  I’ensemble  des  equipements  et  d'une  Installation  d'essais  programmable.  En  effet,  ie  plupart  des 
Informations  intdrassantes  circulent  sur  le  dlgibus  auquei  est  rellde  I'lnstallation  d'essais.  II  n'est  pas  possible 
d'enregistrar  tous  les  para  metres  du  digibus,  mats  on  peut  programmer  trbs  rapldement  la  llste  (^informations  6 
enregistrar  en  fonctlon  de  I’essal  qui  va  itre  effectud. 

Le  rdle  des  avions  prototypes  est  d'sssurer  la  mise  eu  point  finaie  en  vol  et  dans  les  conditions  rdellet  d'envlronnement 
de  toutes  les  fonctions  opdrationnelles,  d'sssurer  les  vols  ddfinltifs  d*evaluation  des  utilisateurs  ot  d'sssurer  la  demikra 
validation  des  standards  de  logiciel  serie  avant  Introduction  sur  la  chatne  de  production. 
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4  -  CONCLUSION 

L'organisation  du  travail  de  la  coordination  et  la  liste  des  moyens  de  dbveloppement  du  MIRAGE  2000  n'ont  pas  ete 
definis  an  un  seul  jour  :  c'est  le  rdsultat  experiences  nombreuses.  Auparavant  des  programmes  d'avions  avec  systbme 
d'armes  moins  complexe  qu  celui  du  MIRAGE  2000  avaient  dbjb  connu  une  certaine  forme  de  coordination  industrielle  en 
liaison  avec  les  Services  Techniques  de  l'Etat  et  l'Armee  de  l'Air.  Par  ailleurs  des  bancs  d'intdgration  et  plus 
particulibrement  la  stimulation  avaient  dbjb  ete  utilises  pour  des  programmes  antbrieurs.  Toutes  ces  mbthodes  ont  ete 
blahorbes  et  expbrimentbes  b  l'occasion  de  ces  programmes  et  l'organisation  employee  pour  le  MIRAGE  2000  en 
represente  l'aboutissement  actuel  sous  la  forme  la  plus  formalisbe  et  la  plus  achevbe. 

Ces  mbthodes  de  travail  et  ces  moyens  de  dbveloppement  ont  montrb  leur  efficacitb  par  un  nombre  rbduit  cTheures  de 
vol  sur  MIRAGE  2000  prototype  pour  aboutir  b  des  fonctions  opbrationnelles  rbpondant  aux  demandes  des  utilisateurs.  11 
en  est  rdsultd  des  coOts  globaux  raisonnables  et  des  dblais  relativement  rbduits  pour  assurer  la  mise  au  point  de 
fonctions  particulibrement  complexes  dans  un  systbme  de  trbs  haut  niveau  d'intbgration  et  comprenant  de  nombreuses 
innovations  techniques,  technologiques  et  opbrationnelles. 

Ces  principes  sont  dbsormais  appliques  b  tous  les  programmes  nationaux  de  systbmes  complexes  embarqubs  dbs  le  stade 
Jes  d/j  L t  Jt  la  uUuuepliut.  ch.tiaill.  HGui  Its  p.  og.  atlilTTCS  expuit,  iiuuS  tuts  ii.lfuitlifcfi  utiiisuua  itS  i> (6 1 i'i_d 

mbthodes  avec  cependant  un  allfegement  des  procedures  du  fait  de  l'absence  des  Services  Techniques  et  de  1'Armbe  de 
l'Air. 

Hai  trfMVTU'U  rim-'rdJ  I  !l  ydW'hnH  Pf  r*oi)v  6jjp»r“  •  ^rr.  f  - 1  i.Mi  P  n  ^  ir*- 

actuellement : 

.  La  formulation  des  specifications  de  logiciel  des  bquipements.  11  s'agit  d'un  problbme  gdndral  sur  lequel  de 
nombreuses  btuoes  sont  en  cours  b  travers  le  monde  entier.  A  notre  connaissance  aucune  solution 
totalement  satisfaisante  n'a  encore  ete  trouvbe  qui  rbponde  aux  exigences  suivantes :  redaction  par  une 
personne  connaissant  bien  la  definition  du  systbme  mais  pas  particulibrement  l'informatique,  lecture 
comprehensible  par  un  non  informat icien,  analyse  exhaustive  de  tous  les  ca3  envisageables,  possibilite  d'en 
ddduire  directement  (par  des  methodes  b  dbfinir)  le  logiciel  correspondent,  maintenance  aisbe  du  logiciel. 

.  L'extei isiui i  ut  id  bUuiuiutiuii.  La  blmiuid.io. i  pibsentu  u'au.aiii  plus  l  iMlerSt  queue  peiitiel  de  faLe 
fonctionner  en  temps  rbel  un  maximum  de  fonctions  des  equipements  reels.  II  s'agit  dans  ce  but 
d'enregistrer  les  informations  le  plus  en  amont  possible.  C'est  essentiellement  pour  les  capteurs  et  plus 
pairicu#Tisi.ercT  puar  le  principal  dterjtTt  as*  le  raoar  qua  le  pnjtn&h*  331  push.  H&is  i-i  tawe  pour  eete 
disposer  de  matbriels  embarquables  pas  trop  volumineux  et  capable3  d'enregistrer  de  trb3  grandes 
quantitbs  d'informations  b  trbs  haute  frequence. 


Js 
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DISCUSSION 

W.Vogl,  Ge 

What  are  your  plans  for  mechanisation  and  to  which  extent,  to  establish  methods  and  capabilities  for  automatic 
comparison  of  actually  measured  parameters  with  those  data  theoretically  defined  or  calculated? 

Author’s  Reply 

Aujourd’hui  il  n’y  a  pas  de  comparaison  automatique  entre  les  parametres  enregistrds  rdellement  et  les  parametres 
thtoriques  utilises  pour  la  definition.  II  n’y  a  pas  de  telle  comparaison  automatique  de  prdvue  pour  l’avenir,  du 
meins  pour  un  avenir  proche. 
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Crew  Station  Evaluation  In  a  Dynamic  Flight  Simulation  Facility 

Jacob  Eyth  Jr. 

Project  Engineer 


Naval  Air  Development  Center 
Warminster,  Pennsylvania  18974 
United  States  of  America 

SUMMARY 

Naval  Air  Development  Center  Is  developing  a  Dynamic  Flight  Simulator  (DFS)  which  will  be  used  to 
evaluate  xfrew  Station  design  concepts  in  the  total  G-force  environment  associated  with  controlled  or  uncon¬ 
trolled  flight  of  high  performance  military  aircraft.  The  DFS  combines  the  Center's  unique  human  centrifuge 
with  a  high  fidelity  aircraft  cockpit,  computer- generated  visual  display  system  and  a  digital  computer 
control  system  to  become  the  world's  first  pilot-controlled  simulation  facility  capable  of  reproducing 
the  multidirectional,  rapidly  varying  and  sustained  G-proflles  of  actual  flight.  The  DFS  will  permit 
the  evaluation  of  advanced  aerodynamic  configurations,  cockpit  displays  and  controls,  crew  systems  and 
weapon  systems  in  a  flight  envelope  which  far  exceeds  that  of  ln-fllght  simulation  or  flight  tests.  The 
relative  safety  of  the  pftaamlE  J&tght^S  fmu  1  a  t  o^~  enables  hazardous  flight  regimes,  such  as  spins  and  depar¬ 
tures,  to  be  investlgatecTTn  a  repeatable,  statistically  accurate  fashion  consistent  with  research  and 
development  evaluation  facilities. 

As  an  adjunct  tc  the  DFS,  the  Center  operates  the  Crew  Station  Evaluation  Facility  (CREST)  to  demonstrate 
and  Integrate  current  and  emerging  control  and  display  technology,  and  to  ensure  operator /system  compatibil¬ 
ity  early  in  the  design  cycle  of  Navy  aircraft.  The  CREST  laboratory  complex  Is  a  total  jtiiman  -Factors 
design  and  validation  facility  which,  when  used  in  conjunction  with  the  DFS,  allows  new  crew  station  equipment 
to  be  developed  and  tested  prior  to  dynamic  evaluation  In  the  DFS.  ^ _ 


This  paper  will  explain  the  unique  capabilities  and  design  of  the  Dynamic  Flight  Simulator  and  Crew 
Station  Evaluation  Facility  as  they  pertain  to  avionics  systems  development  and  validation.  The  NAVAIRDEVCEN 
considers  these  facilities  as  national  resources  which  can  be  used  by  the  free  world's  aerospace  community 
to  solve  today's  human  Interface  problems  and  avoid  tomorrow's.  It  Is  expected  that  this  capability  for 
pre-flight  man-ln-the-loop  evaluation  of  aircraft  systems/subsystems  during  early  phases  of  development 
will  diminish  the  probability  of  problems  surfacing  during  flight  tests  and  will  ultimately  reduce  the 
cost  and  time  required  for  operational  deployment. 


INTRODUCTION 

The  Dynamic  Flight  Simulator,  or  the  DFS,  is  a  manned  full  system  simulation  facility  which  reproduces 
the  total  G-force  environment  common  to  modern  high  performance  aircraft.  Its  development  was  directed  by 
the  U.S.  Navy's  Chief  of  Naval  Material  to  fill  the  need  for  a  safe  platform  to  be  used  In  the  evaluation 
of  pilot  related  problems  during  controlled  and  uncontrolled  flight  of  military  aircraft.  The  Dynamic 
Flight  Simulator  Is  nearing  completion  at  the  Naval  Air  Development  Center  and  Is  In  Its  final  Integration 
phase  with  Initial  operation  scheduled  for  mld-1983. 

The  Crew  Station  Evaluation  Facility  provides  researchers  with  the  capability  to  demonstrate,  evaluate 
and  Integrate  current  and  emerging  control  and  display  technology  and  crew  station  designs  to  ensure  opera¬ 
tor/system  compatibility  early  in  the  design  cycle  of  Navy  aircraft.  The  CREST  consists  of  four  laborato¬ 
ries:  (1)  the  Interactive  Crew  Station  Simulation  Lab  (2)  the  Decision-Making  And  Voice  Technology  Experi¬ 
mental  (DAVE)  Lab,  (3)  the  Computer-Aided  Design  Lab,  and  (4)  the  Static  Crew  Station  Simulation  Lab.  The 
laboratory  complex  Is  a  total  Human  Factors  design  and  validation  facility  which  allows  new  crew  station 
equipment  to  be  developed  and  tested  prior  to  dynamic  evaluation  in  the  DFS.  The  inherent  hardware  and 
software  compatibility  of  the  CREST  and  DFS  allows  a  smooth  and  efficient  transition  from  static  mock-up 
to  dynamic  evaluation,  resulting  In  a  coordinated  approach  to.  solving  crew  station  design  problems. 

BACKGROUND 

The  need  for  a  total  G-force  environment  crew  station  evaluation  facility  has  long  been  recognized. 
This  Is  particularly  critical  In  programs  where  rapidly  applied,  multidirectional,  sustained  G  profiles 
are  Involved.  Such  profiles  are  generated  during  air  combat  maneuvers,  missile  evasive  maneuvers,  close 
air  support  and  weapons  delivery  and  during  uncontrolled  flight,  such  as  the  entry  and  steady  state  phases 
of  spin.  The  excursion  and  velocity  constraints  of  six  degree-of-f reedom  motion  base  systems,  which  are 
traditionally  used  for  flight  simulators,  confine  their  accelerations  to  the  leading  portion  of  a  simulated 
C  profile.  A  number  of  techniques  such  as  G-seats,  G-aults,  seat  shakers,  cockpit  dinning,  and  helmet 
loading  systems  have  been  used  as  C-culng  devices  to  complement  the  limited  motion  capability  of  these 
simulators.  As  effective  as  these  devices  may  be  In  Imparting  a  perception  of  the  G-force  environment  to 
be  simulator  pilot,  they  do  not  Impart  Its  disabling  or  possibly  Its  Incapacitating  effects.  These  effects 
can  only  be  produced  by  a  centrifuge-type  device  or  the  aircraft  Itself. 

Tha  NAVAIRDEVCEN  human  centrifuge  Is  uniquely  qualified  to  perform  In  Its  role  as  the  aotxm  and  force 
base  for  the  Dynamic  Flight  Simulator.  Originally  commissioned  In  1952 ,  the  centrifuge  was  upgraded  with 
major  Improvements  to  its  structural  configuration  and  control  system  In  1964  and  Is  endowed  with  a  number 
of  outstanding  featuras  which  have  never  been  successfully  duplicated  In  any  other  man-rated  centrifuge. 
A  number  of  previous  aircraft  simulation  programs,  covering  a  broad  spectrum  of  flight,  have  been  conducted 
on  the  NAVAIRDEVCEN  cantrlfuge.  These  Include:  severe  air  turbulence  In  a  B-720  aircraft;  spin  simulation 
of  the  F-4  and  F-14  aircraft;  high  G  with  buffet  In  an  F-4;  night  catapult  launching  In  an  A-7;  and  the 
emergency  descent  of  a  high  altltude/multl-mach  transport  aircraft.  Though  these  programs  clearly  demon¬ 
strated  the  potential  of  the  centrifuge  method  of  flight  simulation,  they  also  Identified  specific  areae 
which  should  be  Improved  to  achieve  this  potential.  These  areas  have  been  significantly  upgraded  during 
the  development  of  the  DFS,  and  the  centrifuge  has  now  achieved  its  potential  as  a  full  system,  total 
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G-force  environment  flight  simulator. 

The  Crew  Station  Evaluation  Facility  provides  a  unique  opportunity  for  the  integration  of  hardware, 
software,  and  human  engineering  efforts  into  the  crew  station  development  process.  CREST  evolved  from  a 
previous  advanced  engineering  effort,  the  Advanced  Integrated  Display  System  (AIDS)  Program.  This  program 
developed  two  AIDS  Simulators,  a  tandem  cockpit  and  a  side-by-side  cockpit,  which  are  a  major,  integral 
element  and  capability  within  the  CREST.  The  AIDS  concept  consists  of  providing  a  laboratory  capability 
for  total  Integration  of  controls,  displays,  and  software  with  actual  flight  capable  equipment,  such  as 
the  AYK-14  general  purpose  militarized  computer,  using  only  a  MIL-STD-1553B  multiplexed  data  bus,  and  a 
video  bus. 

Other  areas  of  the  CREST,  including  the  Decision  Making  and  Voice  Technology  Experimental  Lab  (DAVE), 
the  Computer-Aided  Design  lab,  and  the  Static  Crew  Station  Simulation  lab,  are  still  in  the  conceptual 
or  system  integration  phases. 


DESCRIPTION  OF  THE  DFS 

The  DFS  is  a  complete  flight  simulation  facility  which  can  operate  on  or  off  of  the  NAVAIRDEVCEN  Human 
Centrifuge.  A  block  diagram  of  the  overall  system  is  shown  in  Figure  1.  Functionally,  the  Dynamic  Flight 
Simulator  can  be  broken  down  into  four  primary  components.  The  first  component  is  a  newly  developed  multi¬ 
purpose  crew  station  which  contains  a  reconf igurable  single  seat  aircraft  cockpit  with  active  flight  con¬ 
trols,  instruments  and  displays.  The  motion  base  for  the  crew  station  is  the  Naval  Air  Development  Center's 
unique  human  centrifuge  which  has  been  proven  and  refined  over  30  years  of  use.  The  integrated  crew  station 
and  centrifuge  is  linked  to  a  series  of  computers  and  their  associated  control  stations  which  manipulate 
and  transfer  the  real-time  digital  and  analog  data  for  the  DFS.  The  fourth  major  component  is  the  NADC 
Central  Computer  System  which  is  used  to  perform  the  system's  aerodynamic  modeling  and  data  processing. 

Multipurpose  Crew  Station 

The  DFS  Crew  Station  is  a  multipurpose  reconfigurable  cockpit.  It  is  driven  by  the  simulator  control 
system  while  in  either  a  ground  station/static  mode,  or  in  the  centrifuge/dynamic  flight  mode.  The  cockpit 
contains  a  removable  cockpit  panel  assembly,  an  operational  aircraft  throttle,  a  stick/rudder  control  loader 
system,  an  ejection  seat  and  a  structurally  reinforced,  real  world,  scene  generation  system  (see  Figure  2). 
The  cockpit  panel  assembly  is  constructed  as  a  removable  drawer  which  can  be  easily  replaced  to  represent 
different  cockpit  designs.  The  assembly  contains  active  flight  and  engine  instruments,  multipurpose  full 
color  displays,  and  a  programmable  Head-Up  Display  (HUD).  The  cockpit  has  been  designed  with  adjustable 
down  vision,  panel  width,  pilot-eye-to-panel  and  ejection  envelope  dimensions  which  enable  it  to.be  recon¬ 
figured  to  closely  represent  any  single  seat  aircraft  cockpit.  For  additional  realism,  the  cockpit  can  be 
Independently  shaken  to  simulate  buffeting  superimposed  on  the  G-force  environment. 

Visual  Display  System 

The  visual  display  system  provides  real-time  through-the-window  scenes  representing  the  outside  environ¬ 
ment.  The  system  uses  virtual  image  optics  with  a  48°  x  32*  field  of  view.  In  addition  to  basic  day,  dusk 
and  night  Illumination,  landing  light  illumination,  weather  effects  and  moving  target  images  can  be  simula¬ 
ted.  Models  of  various  landing  fields,  an  aircraft  carrier  and  a  mountainous  terrain  scene  are  currently 
aatUeUe*  rhs  S  Mg*  u'Jmt*  tin,  is  muiftrUrr  jo  gism  1 1;  isaa:  tx  ml1  emocrh  mti  m.  up  t~j  a  jiv  tatm  nf 
180*/sec  and  is  synchronized  with  the  aircraft's  changes  in  position,  attitude  and  velocity,  for  full  visual 
cuing. 

Human  Centrifuge 

The  R*v*l  Air  Leveitpmef.t  Cerxet  tentiifag*  1*  the  most  powerful  degree  - .  4  -f  rredofl.,  Tjme.i  rated 
centrifuge  in  the  world.  It's  unique  features  Include:  a  30-foot  long  arm  which  minimizes  G  gradient  and 
Coriolis  force  problems;  a  controllable  dual  gimbal  system  on  the  gondola  which  enables  replication  of  an 
almost  unlimited  range  of  multidirectional  G  profiles;  a  16,000  hp  drive  motor  which  provides  a  10  G/sec- 
ond  onset  rate  between  1.3  and  1SG;  a  40,000  G-pound  payload  capability,  which  will  allow  the  typical  2,300 
pound  cockpit  and  pilot  to  be  accelerated  to  IS  G's. 

The  centrlfuga's  10-foot  diameter  gondola  is  suspended  in  a  controllable  dual  gimbal  system.  The 
gondola  is  environmentally  controlled  and  contains  a  3,000  PSI,  hydraulic  actuator  to  oscillate  the  cockpit 
for  simulation  of  buffat  or  air  turbulence  superimposed  on  the  G-environment  generated  by  the  centrifuge. 

Experienced  engineers  control  all  runs  of  the  cantrlfuge  following  well-defined  standard  operating 
procaduras.  A  biomedical  support  team  monitors  all  human  centrifuge  experiments  by  instrumenting  the 
subject  for  physiological  data  collection.  Tha  flight  surgeon,  along  with  two  other  key  operators  and 
several  automatic  controls,  can  shut  down  tha  system  to  protect  both  the  subject  and  equipment  in  case  of 
an  emergency. 

Data  Processing  Area 

The  heart  of  the  real-time  simulation  capability  of  tha  DFS  is  the  Naval  Air  Development  Center's 
Central  Computer  System.  The  system  consists  of  two  malnframs  central  processing  units,  a  CDC-6600  and  a 
t/bti  170,  10  fruat-tud  and  control  processors  and  a  Tull  complement  bt  peripheral  equipment.  Tne  OTS 
software  performs  thrae  major  functions  for  the  experiment:  full  aerodynamic  simulation,  execution  of  the 
cantrlfuge  control  algorithm,  and  data  collection  and  storage.  The  DPS  aerodynamic  modal  has  bean  designed 
for  utmost  flexibility  when  changing  from  one  aircraft  to  another.  Standardised  aerodynamic  data  is  accessed 
via  look-up  tables  in  a  three-dimensional  format  so  that  changing  aircraft  models  can  be  dona  without  repro- 
graamlng  simply  by  accessing  a  dlffarant  sat  of  look-up  tahles.  The  unlimited  data  storage  available  to 
the  system  enables  ant  Ira  experiments  to  be  stored  and  replayed  for  post  run  analysis. 


36-3 


DFS  Software  Modeling 

The  current  DFS  control  software  includes  an  F-14  aerodynamic  data  package,  a  digital  flight  control 
system,  trim  system  and  the  control  algorithms  for  the  centrifuge  drive,  instrumentation,  and  visual  display 
system.  The  software  generates  all  aircraft  forces  and  moments  using  non-llnearlzed  equations  of  motion 
and  three-dimensional  data  storage  for  all  non-linear  engine  and  aerodynamic  data. 

The  flexibility  of  the  DFS  software  is  particularly  apparent  in  the  aero  data  package.  This  package 
is  capable  of  being  changed  from  one  aircraft  to  another  without  reprogramming  and  to  input  asymmetries  in 
mass,  engine,  or  aerodynamic  features  as  required  by  the  experiment  scenario.  It  has  no  singularities  in 
its  earth  referenced  attitude  angles,  and  permits  large  angular  excursions  in  angle-of-attack  and  sideslip. 

A  distinguishing  feature  of  the  DFS  in  its  initial  configuration  as  an  F-14  spin  simulator,  is  its 
ability  to  fly  in  the  extreme  high  angle-of-attack  (AOA)  regime.  In  this  environment,  the  aerodynamic 
force  and  momenta  typically  change  very  rapidly  and  unexpectedly  with  changes  in  the  orientation  of  the 
free  stream  velocity  vector.  The  aircraft  may  undergo  extremely  violent  excursions  so  that  any  state  of 
equilibrium  may  be  simply  a  very  brief  transient  state.  For  this  reason,  the  usual  linearization  of  the 
rigid  body  dynamic  equations  is  inappropriate  and  so  full  non-linear  rigid  body  dynamic  equations  have 
been  used. 

The  DFS  F-14  aero  data  package  is  the  same  package  which  is  used  in  the  NASA-Langley  and  NASA-Dryden 
simulators  with  the  exception  that  rotary  balance  data  for  the  F-14  has  been  added  to  augment  the  high  AOA 
regime.  The  rotary  balance  data  was  generated  for  the  DFS  by  Bihrle  Applied  Research  at  the  Langley  spin 
tunnel  and  represents  the  most  complete  F-14  high  AOA  and  spin  mode  data  available.  This  data  is  expected 
to  significantly  improve  the  fidelity  of  the  planned  F-14  Spin  experiments. 

Centrifuge  Control  Algorithm 

Another  state-of-the-art  improvement  incorporated  in  the  DFS  ia  the  implementation  of  a  new  centrifuge 
control  algorithm.  In  the  past,  the  three  drive  motors  of  the  NAVAIRDEVCEN  centrifuge  were  programmed  to 
provide  linear  accelerations  to  a  gondola  subject  without  considering  the  angular  artifacts  generated  while 
the  gondola  rotated  from  one  orientation  to  another.  Figure  3  shows  the  positions  of  the  pilot  which  are 
necessary  to  simulate  the  various  G-profiles.  To  reduce  these  angular  artifacts  and  improve  the  flyablllty 
of  the  DFS,  a  new  centrifuge  control  algorithm  waa  developed  which  improves  the  fidelity  of  tha  pilot's 
perceived  angular  motions. 

The  new  control  algorithm  uses  the  concept  of  rotating  linear  vectors  to  counter-influence  the  stimuli 
of  the  angular  accelerations.  With  this  method,  the  disconcerting  angular  artifacts  can  be  effectively 
cancelled  out.  The  new  centrifuge  control  algorithm  and  the  method  used  to  generate  it  are  universally 

Sj-pUeabi#  *Oj  Stonld  fe  emdUilU  in  the-  ■teestopwit  M  3  Klir.eM.e1  t&  wmHWi  elgotilfan  rjl  elj. 
base  syetems. 

DFS  Control  Stations 

lhere  ate  three  integrated  concfol  stations  Which  are  manned  during  All  dynamic  DJa  experiments;  (1) 
the  Experiment  Control  Station,  (2)  the  Centrifuge  Control  Station  and  (3)  the  Flight  Deck. 

The  Experiment  Control  Station  includes  a  graphics  monitor  which  displays  the  resl-tlme  parameters  of 
the  UiUMLm  ttpMlMtfl .  The  an  14  the  sciawy  -mtati  tsnttf  ltd  !M  Lfl  and  nit  as  I  he  it's  wcutige 
area  for  signals  going  to  or  from  the  DFS  cockpit  and  the  Data  Procaselng  area.  The  ECS  operator  has  tha 
ability  to  request  and  monitor  any  data  naceesary  to  tha  experiment  including  mode  and  control  commands  to 
the  simulator  control  system,  data  base  changes,  and  visual  ecene  changee.  A  HIL-STD-1553B  link  to  the 
cockpit  enable*  uthet  lilJB  compatible  aircraft  systems  to  tbUuTiUata  with  the  cockpit  flight  Instruments. 

The  Experiment  Control  Station  contains  a  graphics  display  which  monitors  the  real-time  parameters  of 
the  simulation  experiment.  Also  at  this  station  la  the  graphics  generation  hardware  for  the  visual  display 
system,  cockpit  displays  and  the  head-up  display. 

The  centrifuge  control  Station  provide*  viiual  and  electtotic  mom  coring  oi  the  tentiiluge  operation* 
and  Includes  emergency  shutdown  controls  in  the  event  of  a  system  interruption.  Three  EAI  231R  general 
purpose  analog  computers,  represent  the  centrifuge  control  ayatam.  These  analog  computers,  which  were 
previously  the  only  computers  used  to  control  the  centrifuge,  now  function  to  condition  and  limit  digital 
algnals  coming  from  the  DFS  control  syatea,  and  to  program  the  drive  motors  during  starting  and  stopping 
aequences. 

The  Centrifuge  Flight  Deck  provides  an  overall  view  oi  the  DFS  during  the  operational  portion  of  any 
experiment.  Personnel  In  charge  of  directing  the  experiment  are  stationed  here,  including  tha  project 
officer,  the  flight  director  and  the  medical  officer.  A  biomedical  support  team  la  also  on  duty  at  this 
station  to  continually  monitor  the  physical  status  of  the  simulator  pilot. 

DFS  Hodes  of  Operation 

Independence  of  the  DFS  Experiment  Control  Station  and  tha  Centrifuge  Control  Station  allowe  the  DFS 
to  be  used  in  several  modes  of  operation.  In  addition  to  total  system  dynamic  flight  operation,  tha  DFS 
Crew  Station  station  can  be  used  in  a  fixed  bees  soda  for  experiments  or  phases  of  programs  which  do  not 
require  the  force  environment  provided  by  the  centrifuge.  The  cockpit  instruments  and  visual  display 
system  are  driven  by  the  Experiment  Control  Station  to  provide  any  visual  or  auditory  cues  required. 

As  an  option,  tha  centrifuge  may  be  used  in  an  open  loop  mode  at  any  time.  In  this  mode,  the  centrifuge 
has  no  pilot  feedback  and  la  prograamed  to  perform  a  pre-determlned  force  profile  upon  the  subject. 
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During  normal  full-up  dynamic  flight  simulation,  the  Crew  Station  Is  mounted  In  the  centrifuge  gondola 
and  the  simulator  control  system  assumes  control  of  the  centrifuge.  The  pilot  then  tliea  the  simulated 
aircraft  in  a  closed  loop  total  force  environment. 

CREST  DESCRIPTION 

The  Crew  Station  Evaluation  Facility  ia  being  designed  as  a  laboratory  development  tool  to  be  used  during 
exploratory  and  advanced  development  integration,  and  leboratory  test  and  evaluation  of  crew  station/avionica 
systema.  System  integration  in  CREST  addresses  the  incorporation  of  hardware,  software,  and  human  integra¬ 
tion  efforts  into  the  system  development  process. 

The  three  major  advanced  technologies  which  can  be  evaluated  in  CREST  are  Displays,  Flight  Control 
Integration,  and  Human  Fectors  Engineering.  The  interrelated  but  diatinct  requirements  of  each  of  these 
technologies  defined  the  equipment  configuration  of  the  CREST  laboratory  complex.  The  floor  plan  of  the 
CREST  leboratory  is  shown  in  Figure  4. 

Interactive  Crew  Station  Simulation  Lab 


The  two  AIDS  cockpits  which  represent  the  primary  staging  area  of  the  CREST,  along  with  their  external 
view  projection  systems,  are  located  in  the  Interactive  Crew  Station  Simulation  Lab. 

Tandem  Cockpit:  Controls/Dlsplays 

The  tandem  cockpit  contains  six  reprogrammable  multipurpose  displays,  four  in  the  front  seat  and  two 
in  the  beck,  an  active  side-arm  controller  and  a  generic  throttle,  a  voice  recognition  system,  and  a  hel¬ 
met-mounted  display  system  (see  Figure  5).  A  simulated  Head-Up  Display  (HUD)  ia  projected  on  a  7-foot 
TV  projection  screen  approximately  12  feet  in  front  of  the  cockpit.  Video  tapes,  simulation  models,  or 
scenes  from  a  terrain  model  board  can  also  be  projected  on  the  screen  to  represent  a  real  world  scene 
while  slmulteneously  presenting  HUD  symbology. 

The  Vertical  Situation  Dlaplay  (VSD)  located  in  the  center  of  the  front  seat  cockpit  panel  is  a  raster 
dlspley  which  presents  either  flight  control  or  sensor  information.  The  VSD  flight  display  is  similar  to 
that  of  the  HUD  end  either  may  be  used  in  cese  of  an  equipment  malfunction.  The  VSD  can  also  present  sensor 
information  from  redar,  low-light  level  television,  or  television  camera  guided  missiles. 

The  Horizontal  Situation  Display  (HSD) ,  located  directly  below  the  VSD,  is  a  rester  display  which 
presents  both  tactical  and  navigation  information.  It  may  elao  be  used  as  a  backup  for  the  VSD.  The  HSD, 
depending  on  the  mission  mode,  may  show  a  minimum  time  curve  for  ascent,  e  compass  rose  with  heading  com¬ 
mands,  elrcraft  and  target  symbology,  a  moving  mep,  and  numeric  readouts  for  time,  position,  communications 
channels,  and  fuel  data. 

The  Right  Sltuetlon  Advisory  Display  (RSAD)  is  a  stroke  display  which  presents  generel  aircraft  system 
monitoring  information  in  an  alphanumeric  format.  The  Left  Situation  Advisory  Dlspley  (LSAD)  is  a  stroke 
display  which  presents  alther  angina  management  information  or  weapons  status  information.  As  with  the 
VSD  end  HSD,  either  Situation  Advisory  Dlspley  may  be  used  as  a  backup  for  the  other. 

Pilot  ectuated  switches  are  contained  in  two  sets  of  touch  sensor  controls.  The  Mission  Mode  Controls 
(MMC)  ere  e  set  of  16  buttons  used  for  determining  display  formats  for  various  mission  segments  such  as 
preflight,  climb  out,  dash,  or  air-to-eir.  The  Integrated  Control  Set  (ICS)  is  e  group  of  43  buttons  end 
e  forcestlck  used  for  determining  the  type  of  mission  to  be  flown,  where  dlspley*  ere  to  be  shown  end  whet 
information  will  be  displayed,  numerical  Inputs  to  the  computer,  and  general  pilot/computer  communications. 

The  flight  controls  include  e  side  arm  controller,  two  throttles,  and  15  euxlllery  switches  including 
engine,  flight,  end  weapons  controls.  Also  included  ere  vocelly  actuated  switches. 

The  eft  crew  station  contains  e  raster  dlspley  which  duplicates  the  front  seat  information  and  a  Tactical 
Information  Display  (TID)  which  has  not  yet  been  activated. 

Slde-by-Slde  Cockpit;  Control*  Dlspleys 

The  slde-by-slda  cockpit  is  currently  being  Integrated  into  the  CREST.  Whan  complatad  it  will  contain 
six  three-color  general  purpose  rester  dlspleys  driven  by  e  rester  symbol  generetor.  Side  era  controllars 
end  throttles  ere  provided  for  both  the  left  and  right  pilot  stations.  The  side-by-side  cockpit  utilises  a 
reel-world  scene  end  HUD  projection  system  similar  to  the  one  used  for  the  Tandem  Cockpit. 

Cockpit  Control  Computer* 

The  computers  which  currently  control  both  cockpit  simulations  ere  a  NOVA  820  and  e  NOVA  800  minicom¬ 
puter.  The  computers  ere  located  in  the  Electronics  Bay  Area  of  the  CREST.  The  NOVA  820  functions  es  tha 
I/O  (input/output)  controller  for  the  cockpit  displays  end  controls.  The  NOVA  800  performs  the  required 
functions  on  the  I/O  date,  which  the  NOVA  820  receives  end  sends  to  e  6007  Disk  Emulator.  After  the  NOVA 
800  performs  the  required  processing,  the  deta  Is  sent  back  to  the  Disk  Emulator  whera  the  NOVA  820  raeds 
it  end  performs  the  required  output  function,  e.g. ,  data  updete  for  the  dlspleys.  The  NOVA  820  sod  800 
both  have  32  K  memory  and  era  programmable  In  FORTRAN. 

Two  Frogramsuble  Dlspley  Generetors  provide  the  symbology  for  the  verlous  cockpit  dlspleys.  A  saperete 
Programmable  Signal  Generetor  provides  tha  symbology  for  the  HUD.  Voice  interaction  cepabllity  is  provided 
by  e  V0TRAX  multlllnguel  voice  synthasltar  for  audio  cues  signifying  mode  chengas,  malfunctions,  and 
verlous  edvlsory  sltuetlon*  and  e  Threshold  Voice  Recognition  System  which  provides  c  190-word  branch  control 
cepabllity. 
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As  shown  In  Figure  5,  the  CREST  cockpit  simulation  system  has  access  to  various  peripheral  hardware 
components:  3  Disk  Packs,  console,  console  printer,  paper  tape  reader,  and  a  paper  tape  printer.  A  PDP-11 
with  96K  memory  is  interfaced  with  the  NOVA  820  via  an  RS-232  serial  data  bus.  Eventually  the  PDP-11  will 
assume  the  control  functions  of  the  Interactive  Crew  Station  Simulation  lab,  although  it  is  presently  used 
to  generate  software  to  be  run  on  the  NOVA  820.  An  AYK-14  computer  is  likewise  scheduled  for  Integration. 

Terrain  Model  and  Target  Generator 

uk&ol  dj.su  incxudes  a  Gantry- ierrain  riodei  and  a  Ta.get  Generation  S/otem.  The  G4J.tty-Tei.ai..  HnJtl 
is  located  as  shown  in  Figure  4  and  includes  a  vertically  mounted  22*  x  36',  2000:1  scale,  color  terrain 
board.  The  servo-optical  probe,  capable  of  three  degrees  of  motion,  is  operated  via  the  gantry  and  provides 
input  to  a  high  resolution  TV  system  which  can  display  the  scene  on  TV  Projection  Screens  in  front  of  the 
CREST  cockpits.  The  terrain  board  is  illuminated  via  a  bank  of  fluorescent  lamps  on  the  opposite  wall. 

The  Target  Generation  System  (see  Figure  4  for  location  in  CREST)  consists  of  a  stationary  TV  camera 
aimed  at  two  models  of  a  particular  type  target  aircraft,  control/drive  equipment  and  a  computer  interface, 
v . .it  ' f  t fit.  mOJhsicS  is  miivrrtad  oy  Itu  ball,  till  a t in: t  by  ita  irtjst.  !hu  cmii  ft.  tatetc.  the 
three  axes  so  that  each  aircraft  provides  half  of  the  sphere  of  all  possible  target  aspect  angles.  Together, 
the  two  target  models  can  create  a  target  image  in  any  orientation  which  is  overlaid  upon  the  external 
world  scene  on  the  TV  projection  screen.  The  aircraft  models  which  are  currently  available  are  an  A-4  and 
an  MIG-21. 

Decision-Making  And  Voice  Technology  Experimental  (DAVE)  Lab 

The  DAVE  laboratory  provides  the  capability  to  develop  and  evaluate  new  man/machine  Interfaces  and  to 
establish  design  criteria  for  advance  technologies  such  as  "Smart"  operator  decision  aids  and  speech  recog- 
■rtUutUaynehnele*  dseelupow.*  I  dmgtgu  ts  lasdtf  c*  objJWti**  dftHUjt  (iif3Ut.-4  lei* 
collected  from  simulation  studies  of  the  new  interface  concepts  within  the  DAVE  laboratory.  The  DAVE 
simulation  capability  delivers  reliable  end  valid  data,  which  can  be  directly  utilized  by  the  system  engineer. 
The  DAVE  Lab  is  in  the  process  of  being  Interfaced  to  the  NAVAIRDEVCEN  Central  Computer  system.  Once  this 
is  accomplished,  all  real-time  simulation  will  be  performed  on  a  CDC-6600/Cyber  170  mainframe.  Input/output 
data  from  the  CDC-6600  will  be  utilized  by  the  following  equipment,  which  is  resident  in  the  DAVE  lab: 
(1)  Chromatics  Color  Graphics  Display  system,  (2)  Lambda  LISP  Processor  (3)  Lear  Slegler  Airborne  Voice 
Recognition/Synthesis  System  and  (4)  Group  Decision  aid  Model  1011. 

Computer-Aided  Design  Lab 

The  Computer-Aided  Design  Laboratory  offers  the  capability  of  using  computer  models  for  the  design  and 
evaluation  of  aircraft  crew  stations.  These  computer  design  models  developed  at  NAVAIRDEVCEN  enable  system 
engineers  to  determine  the  Impact  of  existing  and  emerging  control/display  technologies  on  crew  station 
configurations  and  uperater  performance.  The  Ccmput-f  Aided  Ltsi6.  lab  Las  access  to  a  library  A  computet 
models  such  as:  the  Crew  Station  Assessment  of  Reach  Model  (CAR),  and  the  Human  Operator  Simulator  (HOS) 
model,  all  of  which  are  available  to  aupport  work  done  in  the  lab. 

Static  Crew  Station  Simulation  Lab 


trie  Italic  CCam  WrcioC.  thmlsl Lbr  Ulutiitry  U  sfitUIdJIy  daelgmmd  I  of  tiumei  Fa*  lor*  sad  anjlBssr'"! 
evaluations  of  static  mockups  for  any  Naval  aircraft  and  for  the  development  and  evaluation  of  crew  station 
lighting.  This  laboratory  offers  reconf lgurable  mockups  with  the  capability  of  geometrically  reprasentlng 
any  current  or  future  single  seat,  tandem,  or  side-by-aide  crew  station.  In  addition,  the  Static  Crew 
Stetlcn  Labcratsry  has  the  eapaliilty  t*  evaluate  ».e*  aircraft  lighting  teefcn.Kgifcs  eud  it,  dirtt  lighting 
studies  leading  to  improvement  of  outmoded  crew  station  lighting  specifications.  This  lab  is  still  in 
development . 


DFS/CREST  APPLICATIONS 


DfS  Functional  Capabilities 

The  Dynamic  Flight  Simulator  has  brought  the  art  of  flight  environment  simulation  to  its  ultimate 
fora.  This  la  by  virtue  of  its  versatile  and  precise  aircraft  dynamic  modeling,  coupled  with  realistic 
motion,  audio,  vibratory  and  visual  cues  and  a  full  scale  acceleration  field.  While  the  DFS  capabilities 
are  moat  applicable  to  the  exploration  of  those  "•dge-of-the-envelope"  conditions,  which  often  pose  a  hazard 
to  the  aircraft  and  crew  in  actual  flight,  it  is  equally  useful  as  a  conventional  motion  base  simulator  in 
benign  flight  conditions. 

The  Dynamic  Flight  Simulator  can  be  used  by  both  government  and  Industry  as  a  flight  research  facility 
available  at  any  stage  In  an  aircraft's  development  cycle  or  during  its  operational  life.  Often  times  during 
operation,  problems  arise  which  have  not  been  uncovered  in  the  development  cycle.  Usually  these  are  the 
results  of  unaxpected  natural  phenomena  or  penetration  into  flight  regimes  not  previously  predicted  or 
accurately  tested.  The  Dynamic  Flight  Simulator  provides  an  earth-bound,  laboratory  environment  where 
these  altuaticns  can  be  aafely  explored  prior  to  flight  validation. 

The  Dynamic  Flight  Simulator's  utility  in  solving  existing  problems  ranges  from  the  development  of 
piloting  techniques  for  recognising,  avoiding,  or  correcting  departure  or  spin  conditions,  to  the  preflight 
investigation  of  engineering  changes  designed  to  correct  flight  deficiencies  or  undesirable  flight  charac¬ 
teristics. 

Fade  application*  of  the  teuUlluge  have  concentrated  «n  such  ptuMemi  a*  pilot  disot lefalatlui. 
and  reaction  during  night  catapult  launches  from  aircraft  earrlars,  uncontrolled  spinning  flight  of  high- 
performanca  aircraft,  and  clear-air  turbulence  encounters  by  jet  transport  aircraft.  In  each  case,  the 
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Insight  gained  through  these  experiments  have  led  to  better  pilot  recognition  and  Interpretation  of  the 
onset  sensations  as  well  as  confidence  In  applying  corrective  control. 

In  a  similar  vein,  the  DFS  can  be  eaployed  to  Investigate  high  angle-of-attack  flight,  post-stall 
gyration,  alr-coobat  maneuvering  and  low-altitude  terrain  following  flight.  Potentially  hazardous  pilot- 
induced  oscillations  associated  with  high-speed  flight,  landing  approach  and  special  situations  such  as  mid¬ 
air  refueling,  are  other  problems  which  can  be  safely  addressed  In  the  DPS. 

Ao  a  problem  avolder,  the  Dynamic  Flight  Simulator  offers  the  opportunity  to  Investigate  these  and 
other  flight  condltlona  in  advance  of  the  "bending  metal"  phase  of  aircraft  development;  during  the  period 
when  design  changes  are  relatively  Inexpensive  as  compared  to  changes  to  correct  deficiencies  uncovered 
during  flight  test.  The.  art  of  aerodynamic  prediction  through  wind  tunnel  testing  and  numerical  analysis 
makes  data  available  of  sufficient  quality  to  allow  all  but  the  most  subtle  aerodynamic  characteristics  to 
be  accurately  modeled  and  the  resultant  flying  qualities  and  handling  characteristics  to  be  Investigated. 

The  DFS  offers  a  wide  range  of  applications  as  a  result  of  Its  unique  capabilities  for  dynamic  crew 
station  simulation.  Several  of  these  applications  are  listed  below: 

o  Total  Systems  Simulation  o 
o  System/Subsystem  Design  Evaluation  o 
o  Crew  Station  Design  o 
o  Human  Factors  Engineering  o 
o  Procedures/Tactics  Evaluation  o 


Spin  Simulation 
Flying  Qualities 
Specialized  Training 
Accident  Investigation 
Acceleration  Research 


The  DFS  can  be  used  to  evaluate  pilot  performance  and  transfer  of  training  In  high  stress  or  hazardous 
flight  scenarios.  In  this  area,  the  DFS  can  In  fact  safely  exceed  the  performance  of  flight  testing. 

The  expanded  flight  regime  available  In  the  DFS  Is  graphically  portrayed  In  Figure  6.  The  curves 
In  6a  and  6b  show  the  acceleration  environments  associated  with  the  spin  of  a  typical  aircraft.  These 
grepha  of  acceleration  veraua  yaw  rate.  Indicate  that  the  DFS  is  capable  of  operating  safely  In  a  flight 
envelope  encompassing  the  full  regime  of  the  spin.  Duplication  of  this  envelope  Is  not  available  In  any 
other  ground  based  simulator  and  far  exceeds  the  limits  of  a  safe  flight  test  which  Is  shown  In  the  left 
hand  corner  of  the  graph. 

Planned  DFS  Programs 

The  flrat  program  scheduled  to  use  the  full  system  capability  of  the  DFS  Is  a  U.S.  Navy  sponsored  F- 
14  Flat  Spin  Investigation  program.  The  DFS  Spin  Program,  scheduled  for  the  late  1983,  will  Investigate 
pilot  related  problems  Incidental  to  aircraft  stall/depertura,  spin  entry,  and  spin  recovery.  Of  concern 
Is  the  degree  of  pilot  Incapacitation,  pilot  disorientation  or  confusion,  and  excessive  pilot  work  load  at 
a  critical  time  when  a  delay  In  his  being  able  to  recognize  the  true  situation  and  execute  the  proper 
controls  can  result  In  the  loss  of  the  aircraft.  Parametric  variations  will  be  made  In  the  pilot  restraint 
system,  the  cockpit  displays,  and  the  delay  In  pilot  execution.  DFS  pilots  will  be  required  to  perform 
realistic  control  tasks  In  the  apln  environment  while  their  success  rates  are  statistically  tracked. 

The  outcome  of  the  experiment  Is  expected  to  uncover  potential  areas  for  Improvement  In  the  design  of 
the  F-14  controls  or  displays  with  regard  to  spin  warning  or  recovery  systems. 

Follow-on  DFS  programs  will  Involve  spin  studies  for  other  aircraft  and  evaluation  studies  of  new 
syatema/subsystems  for  current  and  future  military  aircraft  during  all  atages  of  their  development.  The  DFS 
Is  projected  for  use  for  speclellzed  flight  trslnlng  for  high  G  and  hazardous  flight  regimes  and  for  out-of- 
c.ontrol  flight  situations.  It  will  also  be  used  as  an  aid  In  certain  eccldant  Investigations  to  recreate 
the  actual  flight  environment  which  preceded  the  accident  In  order  to  determine  what  effect  the  environment 
may  have  had  In  preventing  the  pilot  from  executing  the  proper  controls. 

CREST  Functional  Capabilities 


Functional  capability  of  the  CREST  laboratory  Is  presently  limited  to  the  Computer-Aided  Design  Lab, 
DAVE  lab  end  Interactive  Crew  Station  Simulation  lab.  Using  the  tandem  cockpit,  various  mission  flight 
scenarios  have  bean  run.  The  simulated  missions  have  consisted  of  the  following  phases:  prefllght,  systems 
check,  mission  date  Input,  checklist  for  take-off,  engine  start  sequence,  take-off/cllmb,  dash/lolter,  an 
elr-to-elr  engagement,  return  to  base/lending,  and  postflight.  Other  components  of  CREST  are  In  the 
system  Integration  phases  with  full-up  operation  planned  for  1984. 

CONCLUSIONS 

The  DFS  has  opened  up  a  new  d... .-melon  In  flight  simulation  by  providing  a  flight  environment  heretofore 
unavellsble  to  the  ground-based  elai  itlon  community.  A  wide  spectrum  of  aircraft  systems/subsyatems  can 
now  be  evaluated  under  pilot  eontro.  ’1th  the  authenticity  of  e  flight  test  and  the  safety,  repeatability, 
end  convenience  of  e  simulator. 

The  combination  of  the  powerful  NAYAIRDEVCEN  man-rated  centrifuge  with  reel-time,  man-ln-the-loop 
aerodynamic  simulation  and  a  high-fidelity  crew  station  provides  a  unique  capability  unavailable  on  other 
motion-based  simulators.  No  other  ground  based  system  In  the  world  can  offer  the  realism  of  the  sustained 
G-forces  of  true  flight.  The  DFS  can  provide  a  platform  for  testing  and  training  In  a  safer  and  more 
economical  environment  than  that  of  In-flight  simulation  end  flight  testa. 

As  national  facilities,  both  the  DFS  end  CREST  will  provide  the  Trl-Servlce,  foreign,  and  Industrial 
communities  with  platforms  for  evaluating  new  concepts  In  crew  station  design,  crew  equipment,  restraint 
systems,  end  flight  controls.  As  human  factor  tools,  the  DFS  end  CREST  will  be  uaed  to  evaluate  pilot 
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performance  and  transfer  of  training  In  both  hazardous  flight  regimes  or  benign  environments.  The  pre-flight 
aan-in-the-loop  evaluation  of  aircraft  systems/subsystema  during  early  stages  of  development  will  help  to 
diminish  the  probability  of  problems  surfacing  during  flight  T&E  and  substantially  reduce  the  cost  and 
time  required  for  system  development. 

The  Naval  Air  Development  Center  Is  offering  the  use  of  the  DFS  and  CREST  to  the  entire  aerospace 
community.  In  doing  so.  It  makes  available  a  full  ayatem  development  facility  which  has  not  previously 
been  available  for  the  classical  Research,  Development,  Teat  and  Evaluation  cycle.'  of  military  and  commercial 
aircraft.  Aa  a  newly  developed  capability,  the  full  potential  of  the  DFS/CREST  Is  just  beginning  to 
be  realised.  Interested  users  are  invited  to  consider  their  application  to  the  solution  of  present  crew 
station  design  problems,  and  to  be  imaginative  in  applying  these  facilities  to  future  problem  avoidance.  A 
full  spectrum  of  options  are  available  for  users.  Programs  can  be  run  entirely  by  NAVAIRDEVCEN  engineers 
who  will  plan,  conduct,  and  report  on  the  test,  or  the  user's  own  personnel  can  participate  in  the  design, 
testing,  and  data  acquisition  efforts  associated  with  their  programs.  NAVAIRDEVCEN  is  aware  of  the  need  for 
some  users,  especially  those  In  the  foreign  and  industrial  communities,  to  protect  the  results  of  their 
proprietary  research  and  development  activities  and  is  prepared  to  ensure  the  security  of  any  teats  which 
are  performed.  The  Naval  Air  Development  Center  recognizes  that  the  need  to  assist  users  of  the  DFS  and 
CREST  will  vary  with  their  desires  for  privacy  in  their  work  and  their  need  for  assistance.  In  either  ex¬ 
treme,  the  ..>,...1.  icfuui.t.  j!  the  ClSt  arm  available  It  itti..  ii.  the  t-.i.a.iulng  &ud  tperailub  of 
any  type  of  experiment. 
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DISCUSSION 


J.P.Murgue.  Fr 

Have  you  any  result  about  the  maximum  g’s  condition  which  a  pilot  is  capable  to  stand  whilst  operating  a  Helmet 
Mounted  Sight? 

Author’s  Reply 

We  have  not  tested  a  Helmet  Sight  in  our  centrifuge  although  the  airforce  has  done  HMD  tests  in  the  past.  A 
program  to  test  the  new  HMD  technology  in  the  DFS  would  be  welcomed  but  has  not  as  yet  been  ptanned. 


K.F.Boecking,  Ge 

Can  you  say  something  about  the  costs  per  flight  hour? 

Author’s  Reply 

The  cost  algorithm  is  still  being  developed.  It  is  expected  to  be  competitive  with  other  “moving  base”  flight 
simulations. 


G.Hunt,  UK 

Is  it  your  intention  to  validate  the  high-g  simulator  by  measuring  pilot  performance,  under  similar  acceleration 
conditions  in  an  aircraft  and  in  the  simulator? 

Author’s  Reply 

The  current  validation  effort  is  comparing  actual  F-14  flight  test  data  to  the  simulator  in  the  level  flight  and  high 
angle  of  attack  regimes  for  both  high  and  low  g  manoeuvres.  Spin  test  data  will  be  compared  as  far  as  it  is 
currently  available.  Other  data  has  been  developed  using  wind  tunnel  tests. 


W.H.McKinlay,  UK 

Is  there  any  practical  limitation  as  to  the  rate  at  which  g  can  be  applied  for  example  in  transient  manoeuvres? 

Author’s  Reply 

The  cent"fuge  is  capable  of  a  g-onset  rate  of  1 0  g’s  per  second  which  is  sufficient  to  simulate  most  high  perform¬ 
ance  aircraft.  However,  the  aerodynamic  model  of  the  particular  aircraft  will  regulate  the  actual  onset  rate  to  match 
the  desired  manoeuvre. 


F.W.Broecker,  Ge 

What  kind  of  parameters  (technical  or  human)  are  mainly  recorded  in  your  centrifuge? 

Author’s  Reply 

The  simulator  can  record  all  aerodynamic  parameters  which  are  used  in  the  software  model  and  most  of  the  pilot 
performance  parameters  medical  data  is  also  monitored  for  safety  reasons. 


J.Vaillancourt,  Ca 

Do  you  simulate  the  air  refuelling  function?  If  so  how  do  you  super-impose  the  refuelling  tanker  video  onto  the 
SP-2  Rediffusion  display? 

Author’s  Reply 

It  is  not  implemented  now.  A  tanker  "CGI”  model  is  available  for  the  SP-2,  however,  it  would  probably  not  be 
economical  to  use  in  the  centrifuge  since  “G”  is  not  a  problem  parameter  for  this  type  of  mission. 
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ABSTRACT 

Tornado  avionic  and  weapon  integration  facility  at  MBB-Munich,  which  was  upgra¬ 
ded  in  the  recent  years,  is  presented  in  detail.  The  increased  test  capabilities  are 
pointed  out.  Requirements  for  future  integration  concepts  and  the  according  ground  test 
facilities  are  given.  ‘S$T}7 

1 .  INTRODUCTION 

In  developing  Aircraft  Weapon  Systems  with  complex  avionic  equipments,  the  designer 
is  faced  with  the  difficult  task  of  how  to  adequately  validate  the  system  in  a  realistic 
environment  before  committing  it  to  a  series  of  missions.  In  most  cases  it  is  either  too 
expensive,  time  consuming,  or  the  risk  factor  is  considered  too  high  to  allow  an  exclusi¬ 
ve  series  of  flight  tests.  Thus  appropriate  ground  test  facilities  are  required. 

In  general  a  flying  weapon  system  consists  of  hardware,  software  and  some  non-avio- 
nic  systems  designed  together  to  meet  the  required  mission  abjectives.  In  the  design  pro¬ 
cess  the  flight  hardware  components  are  developed  seperately  by  different  organisations 
using  a  common  set  of  requirements.  Similarly  the  flight  software  is  coded  to  meet  the 
associated  software  requirements.  Finally  hardware  and  sofware  are  brought  together  on 
the  ground  in  an  environment  which  enables  system  checkout  and  integration,  the  so-called 
"Integration  Rig".  The  rig-design  should  provide  computer  aided  real-time  simulations  of 
the  airborne  conditions  at  different  levels.  Only  when  the  ground  operated  system  is  sub¬ 
jected  to  the  same  dynamic  conditions  as  on  a  mission  are  significant  validation  tests 
possible,  and  thus  the  goal  of  avoiding  or  reducing  flight  tests  may  be  realised .This 
paper  will  attempt  to  show  on  the  basis  of  experience  with  the  Tornado  development  phase 
what  can  be  achieved  today  in  this  direction. 

2.  TEST  METHODS  FOR  THE  TORNADO  DEVELOPMENT 

The  main  features  of  the  Tornado  Weapon  System  to  Avionics  are: 
the  highly  integrated  precise  navigation  system 

-  the  terrain  following  system 

-  the  central  mission  Computer  which  performs  all  navigation,  steering,  weapon 
aiming  and  delivery  computations 

-  the  digital  armament  control  system. 

To  achieve  this  it  was  necessary  to  install  a  complex  avionic  system  with  a 
reasonable  interaction  to  nonavionic  systems  wich  are  critical  with  respect  to  flight 
safety.  Thus  a  test  and  integration  concept  was  selected  with  emphasis  laid  on  ground 
based  facilities.  The  Concept  was  comprised  of  five  levels  partly  overlapping  in  time: 

Stage  1:  Development  and  approval  tests  for  Mission  Computer  software.  The  softwa¬ 
re,  coded  and  assembled  with  the  aid  of  a  main  frame  host  computer,  is  loaded  and  run  on 
a  Mission  Computer  which  is  connected  to  a  minimum  of  avionic-  and  selected  test  support 
peripherals. 

Stage  2:  Basic  equipment  integration  of  development  models  and  verification  of 
flight  software  under  laboratory  conditions  by  means  of  a  basic  test  rig. 

Stage  3:  These  tests  are  the  so  called  carrier  aircraft  or  flying  test  bed  trials, 
carried  out  on  major  subsystems  including  Navigation  and  Radar,  expecially  with  respect 
to  the  terrain  following  capability. 

Stage  4:  Tests  carried  out  on  complex  test  rigs  designed  to  support  system  inte¬ 
gration  and  validation  as  well  as  performance  trials  wherever  possible  on  the  ground.  The 
avionic  subsystems  are  connected,  integrated  step  by  step  and  operated  with  flight 
software  in  an  aircraft  like  environment,  which  in  common  is  conveyed  to  the  system  via 
sensor  output  data  and  includes  interaction  with  non-avionic  systems. 

Thus  the  adequate  rig  should  comprise  at  least  simulation  equipments,  by  which  the 
sensors  can  be  modelled  and  substituted.  For  more  comprehensive  tests  however,  it  is 
necessary  to  include  the  sensors  in  the  ground  operated  system  by  stimulating  them 
directly  or  inserting  the  desired  data  near  their  point  of  origin  within  the  sensors. 
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The  stage  4  avionic  rig  at  MBB,  upgraded  in  the  recent  years,  now  including  the 
weapon  system,  many  ' front-end-sensor-stimulation '  devices,  a  signal  link  to  the  flight 
controls  systems  (located  in  a  separate  rig)  and  a  new  data  handling  and  simulation 
system  meets  all  requirements  of  this  test-level.  This  facility  is  described  in  the  next 
paragraph  in  more  detail. 

Stage  5:  Plight  tests  with  prototype  aircraft.  The  idea  of  this  level  is  to  give 
final  performance  verification  trials,  not  to  support  extensive  fault  detection  and  cor¬ 
rection. 

3.  THE  MBB  INTEGRATON  AVIONIC/ARMAMENT  RIG  AND  RELATED  FACILITIES 

The  rig  is  designed  to  support  the  following  tasks: 

o  Hadware  integration.  Basic  electrical  integration  testing  ranging  from  the  indivi¬ 
dual  equipment  level  through  all  intermediate  sub-system  levels  up  to  the  whole  sy¬ 
stem.  Tests  under  static  and  dynamic  signal  conditions. 

o  Software/hardware  integration.  Verification  and  validation  of  mission  computer 

software  in  conjunction  with  the  real  flight  hard-  and  firmware  under  mission  re¬ 
presentative  conditions. 

o  Integration  of  the  avionic/armament  system  with  other  related  systems,  e.  g.  Auto¬ 
pilot  Flight  Director  Fight  Control  System  or  the  aircraft  power  supply. 

o  Confidence  and  performance  testing.  These  class  of  tests  are  considered  essential 
for  the  sub-systems  involved  in  Terrain  Following  (TF). 

o  Investigation  of  the  effectiveness  of  the  man-machine  interfaces 

o  Basic  EMC  studies. 

o  Support  of  flight  tests,  i.  e.  crew  familiarisation  with  test  procedures  as  well  as 
test  data  preparation  and  evaluation. 

In  the  near  future,  when  the  initial  development  phase  is  concluded  the  following 
tasks  are  anticipated,  since  the  rig  has  recently  been  upgraded  to  the  a/c  production 
standard: 

-  Back  up  facility  for  fault  verification,  investigation  and  correction 

-  Hardware/software  development  support  for  future  upgrades/modifications  to  the  Tor¬ 
nado,  for  example  adaptation  of  new  weapons  or  ECM-devices. 

performance  studies  for  modified  or  new  mission  types. 

The  resulting  structure  of  the  test  facility  has  a  central  section  comprising  the 
avionic  and  weapon  components,  including  the  cockpit  area  and  several  special  to  type 
test-equipment/8imulators  which  may  be  connected  to  the  central  rig  or  operated  indepen¬ 
dently  (Figure  1).  These  special  test  facilities  can  serve  as  front-end  stimulation  devi¬ 
ces  for  the  sensors  they  are  built  for.  They  are  remotely  controllable  by  a  medium  size 
digital  simulation  facility  -  which  incorporates  extensive  data  acquisition  and  reduction 
tools  -  or  .by  a  big  high-fidelity  simulation.  The  simulations  differ  in  complexity, 
availability  and  also  expense  in  both  the  direct  and  indirect  sense. 

Other  important  aircraft  systems  are  concentrated  in  separate  but  connectable  rigs, 
namely  the  flight-control  systems  rig  and  the  electric-system  rig. 

In  the  following  a  brief  description  of  all  parts  forming  the  test  facility  is 

given: 

3.1  The  main  Test  Rig. 

The  central  part  of  the  rig  represents  a  simplified  copy  of  the  front  airframe  in¬ 
cluding  the  cockpit.  The  avionic  equipments,  the  autopilot  and  cockpit  control  elements 
can  be  installed  in  their  original  mounting  trays  and  are  connected  by  aircraft  cabling. 

To  access  signals  internal  to  the  avionic  and/or  weapon  system  system  all  important 
devices  may  be  operated  external  to  the  central  rig  on  dedicated  collocated  test  and 
'patch'  panels.  These  panels  are  designed  to  either  work  as  a  stand  alone  test  facility 
with  proper  simulation  equipment,  or  as  an  integral  part  of  the  overall 
Av ionic/Armament-system. 

In  the  same  way  the  following  additional  special  to  type  test  equipments/simulators 
can  be  operated  with  their  sensors,  providing  a  manually  or  computer  controlled  front  end 
or  nearly  front  end  stimuation: 

o  Turntable  for  gyro-stabilized  sensors  providing  variable  attitudes, 
o  Pressure  transducer  stimulator  for  the  Air  Data  Computer 
o  Doppler-,  Radio-Altimeter  and  Tacan-stimulators 


- . .  -  •- 
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o  Radar  test  bench  with  an  absorbtion  chamber,  a  target  simulation  for  the  ground 
mapping  radar  and  a  terrain  simulation  for  the  TF-radar  controllable  only  by  the 
MBB-UF  simulation  centre  (see  Fig.  2) 

o  IR-Target-simulation  for  the  A/A  missile. 

In  addition  to  the  above  devices  an  ECM  test  facility  and  a  self-contained  special 
stand  alone  tester  for  mission  computer  hardware/software  should  be  mentioned  for 
completeness . 

The  cockpit  is  equipped  for  the  two  crew  members  with  the  following  man-machine  in¬ 
terfaces: 

o  Avionic  and  Weapon  Controls,  Keyboards  and  Indicators 

o  Displays  for  the  Radar,  the  main  computer,  the  Head  Up  Display  and  the  TF-display 
(E-Scope) 

o  other  indicators  and  flight  controls,  i.e.  stick,  throttle  levers,  pedals,  wing 
sweep  lever,  which  are  necessary  to  fly  the  a/c  manually. 

Five  main  parts  of  the  weapon  system  are  now  integrated  in  the  rig 

o  the  Stores  Management  System  including  the  gun  electronics  unit 

o  Air-to-Ground  Missile  System  for  the  anti  ship  missile  Kormoran 

o  Air-to-Air  missile  system  for  the  Sidewinder. 

o  Special  Weapon  System 

o  MW-1  (under  contruction) 

3.2  Flight  control  systems  rig 

As  a  further  approach  to  the  goal  of  testing  all  devices  chained  by  interactions  a 
signal  link  to  the  flight  control  rig  was  installed  in  1981.  This  rig  comprises  in  an 
a/c-like  assembly  the  primary  and  secondary  flight  control  systems,  i.  e.  the  Command  and 
Stability  Augmentation  System  (CSAS)  with  the  related  air  data  sensor,  the  rate  gyros, 
the  actuators  for  the  aerodynamic  control  surfaces  like  rudder,  "taileron",  flaps,  slats 
etc.  Additionally  it  provides  an  alternative  operation  capability  for  the  autopilot  and 
has  a  cockpit  equipped  with  controls  and  indicators  necessary  f"r  human  guided/monitored 
flights.  Several  auxiliary  systems  like  the  hydraulic  pumps  or  -he  air  intake  control 
system  are  integrated. 

Thus  -  when  connected  to  an  appropriate  simulation  -  this  facility  enables  detailed 
investigations  of  the  flight  control  system.  A  special  computer  simulation  of  the 
aerodynamic  loads  applied  to  the  control  surfaces  is  noteworthy,  enabling  investigations 
of  the  failure  probability  of  critical  systems  by  long  endurance  tests. 

3.3  Electric  systems  rig 

Another  connection  of  the  Avionic/Armament  rig  is  installed  to  the  electric-systems 
rig.  The  a/c  generators,  transformers,  the  battery  and  the  power  control  unit  form  part 
of  this  facility.  The  important  influence  of  the  on-board  power-supply-system  on  the  air¬ 
craft  electronics  i.  e.  voltage  transients,  ac-frequency  changes  and  interruptions  of  po¬ 
wer  which  may  generate  errors  can  be  investigated  with  this  rig. 

3.4  Computer  aided  data  acquisition/reduction  and  simulation 

The  quality  of  the  test  facility  is  determined  by  the  computer  aided  tools,  which 
are  provided  here  at  two  different  levels:  one  for  multi-purpose  applications  and  simple 
simulations,  called  IDAS,  and  one  for  complex  high  fidelity  simulation  of  the  aircraft 
behavior  under  arbitrary  conditions.  The  smaller  system  is  dedicated  to  the  avionic/arma¬ 
ment  rig,  while  the  greater  system  is  concentrated  at  the  simulation  center  MBB-UF  and  is 
shared  by  several  users. 

3.4.1  The  Integrated  Data  Acquisition  and  Stimulation  System 

The  completely  renewed  IDAS-System  consists  of  a  software  package  and  standard 
minicomputers  (PDP11)  with  appropriate  signal  converters.  The  handling  is  based  on  normal 
plain  English  and  does  not  require  the  knowledge  of  programming  languages.  It  enables  the 
user  to: 

o  Acquire  data  from  the  avionic/weapon  system  under  real-time  conditions  and  record 
them  onto  magnetic  tape/disc  for  subsequent  off-line  reduction  or  later  re-injec¬ 
tion  into  the  system.  For  convenient  data  evaluation  and  replay  additional  user 
written  Fortran-routines  are  linkable.  Data  acquisition  may  also  include  values 
internal  to  the  operational  flight  software,  wich  are  retrieved  via  special  test 
outputs  of  the  mission  computer. 
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o  stimulate  parameters  statically  by  predefined,  repeatably  callable  sets  of  data. 

o  dynamic  data  injection  and  remote  control  of  the  sensor  front-end  stimulation.  The 
avionic/weapon  system  data,  especially  the  sensor  outputs  can  be  substituted 
partially  or  totally.  Another  possibility  to  control  system  data  is  given  by  the 
remote  steering  of  the  special  to  type  test  equipment/simulators.  Data  sources  may 
be  recorded  files  from  either  rig-  or  flight  test  equipment,  or  may  originate  from 
evaluation  of  simple  mathematical  formulas. 

For  example  if  the  test  conditions  require  an  ascent  of  the  aircraft  with  constant 
climb  angle  and  velocity,  an  IDAS-testprogram  can  be  prepared,  calculating  the  in¬ 
creasing  heights  from  the  Air  Data  Computer  and  the  Radio  Altimeter  with  the  cor¬ 
rect  time  dependency. 

On  basis  of  the  formula  evaluation  capability  a  simplified,  low-cost  aircraft  model 
has  been  provided,  allowing  a  'flight'  with  the  avionic  and  armament  systems 
manually  controlled  via  cockpit  controls  or  guided  by  the  autopilot.  The  approxima¬ 
tion  level  of  this  simulation  is  sufficient  for  basic  tests  and  also  crew  fami¬ 
liarisation  with  respect  to  avionic  tasks  and  weapon  delivery  moding. 

o  define  events  and  automatic  actions.  The  test  execution  can  be  based  on  time  with  a 
maximum  action-rate  of  1  KHz  or  on  reaching  predifined  data  values  or  conditions. 

If  e.  g.,  the  data  recorded  during  flight  test  are  to  be  injected  in  a  system- 
configuration,  the  data  stream  can  be  started  some  minutes  after  take-off  and  above 
a  specified  height  reached  during  flight. 

o  reference  all  values  which  form  part  of  the  avionic  input/output  by  a  name;  a  cen¬ 
tral  avionic  data  file  keeps  all  scalings  and  restrictions  giving  a  unique  descrip¬ 
tion  of  the  referenced  variable  by  which  it  is  handled  by  the  software  automatical¬ 
ly.  One  of  the  most  important  features  of  IDAS  is  a  program  which  supports  the  ge¬ 
neration  of  avionic  data  file-versions  belonging  to  different  flight  hardware  and 
software  configurations.  So  investigations  including  various  modification  levels  of 
avion ic/weapon  systems  are  easily  performed. 

o  load  versions  of  operational  flight  software  in  the  mission  computer.  Down  load  of 
flight  software  or  special  system  test  programs  is  supported. 

The  hardware  basis  is  formed  by  two  DEC  PDP11/60  computers  connected  by  an  xnter- 
processor  link  and  equipped  with  standard  peripherals  like  discs,  magnetic-tapes, 
video/paper-terminals  and  a  plotter. 

Additionally  special  interfaces  are  integrated  giving  access  to 

analog  signals  (voltage  levels) 

5  types  of  discrete  signals 
Tornado  serial  signals 

Mil-Std-1 553B  signals-  and  bus-protocol 

PCM-Signals  aa  used  by  Flight  test  equipment  and  Crash  Recorder 
steering  signals  for  the  special  to  type  test  benches/simulators 

3.4.2  The  simulation  centre  at  MBB-UF 

At  this  centre  various  high  fidelity  real-time  simulations  are  available.  Here 
three  special  programs  driving  hardware  in  the  loop  rig-tests  are  of  interest. 

The  basic  computing  system  consists  of  a  Rank  Xerox  Sigma  8  System,  which  is  repla¬ 
ced  now  by  DEC'S  VAX11.  Interfaces  and  programs  are  provided  for  following  main  con¬ 
figurations: 

o  Digital  Simulation  connected  with  the  avionic/armaraent  rig:  The  software  synthesi¬ 
ses  in  real  time  the  fly-by-wire  system,  the  engine  and  the  free  flying  aircraft  in 

6  degrees  of  freedom.  On  basis  of  approximately  70  000  coefficients  nearly  all 
configurations  (wing  sweep,  center  of  gravity,  flap  setting  etc.)  of  the  Tornado 
can  be  modelled. 

Inputs  to  the  programm  are  cockpit  or  autopilot  commands  from  the  rig,  outputs  to 
the  rig  are  values  describing  the  aircraft  state  of  motion  and  attitude  formatted 
as  sensor-outputs,  e.  g.  from  IN,  ADC  or  Doppler  System.  Where  it  is  necessary, 
front-  end  sensor  stimulation  is  possible  by  the  remote  control  of  the  special  to 
type  test  benches/simulators. 

o  Digital  simulation  connected  with  the  flight  control  systems  rig:  Similar  to  the 
previous  case  the  airborne  environment  is  simulated  as  far  as  necessary  for  the 
flight  control  systems.  Especially  the  aerodynamic  loads  are  calculated  and  applied 
via  hydraulic  counteractuators  to  the  flight  control  mechanics. 

o  Digital  Simulation  connected  with  the  linked  Avionic/Weapon  -  and  Flight  Control 
System  rig: 
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This  represents  the  most  powerful  hardware-in-the  loop  configuration.  The  airborne 
environment  is  exactly  simulated  in  the  relevant  variables  for  a  ground  based 
system  comprising  the  avionic/weapon-devices,  the  autopilot,  the  CSAS  and  the 
hydraulic/mechanic  components  of  the  flight  control  system. 

In  the  following  chapter  a  system  test  is  described  concerning  the  automatic  ter¬ 
rain  following  mode  to  convey  an  idea  of  the  capabilities  of  the  above  configura¬ 
tion. 

3.5  Testing  the  Tornado-terrain-following  mode  as  an  example 

In  order  to  achieve  operational  clearance  for  the  Tornado  IDS  automatic  terrain 
following  system  comprehensive  rig  tests  where  necessary,  before  flight  testing  could 
start  at  low  levels.  Test  objectives  where  to  give  an  essential  contribution  to  the  per¬ 
formance  trial,  to  investigate  failure  consequence  and  the  effectiveness  of  warnings. 
Briefly  the  tests  aim  at  creating  confidence  in  the  system. 

The  TP-System  controls  the  flight  path  of  the  aircraft  to  a  preset  clearance  height 
above  the  terrain.  A  terrain  following  computer  generates  a  theoretical  slci-toe  shaped 
envelope  in  front  of  the  plane  and  compares  it  with  radar  returns  from  ground.  If  at  any 
point  terrain  is  found  to  penetrate  into  the  envelope,  an  automatic  pull  up  command  is 
generated  and  passed  to  the  autopilot.  Figure  2  shows  the  structure  of  the  system,  its 
partitioning  on  two  rigs  and  the  signal-flow  with  loops  closed  by  digital  simulation. 

Within  the  Sigma  8  the  free  aircraft  is  modelled.  The  resulting  attitude  and  loca¬ 
tion  of  the  airplane  is  sent  to  a  fast  processor  {miproc  16),  which  calculates  in  real 
tiiow  Ci«  'iflir  rsr.gw  *ir r  respect  to  a  pr^sf-. 1  iSiMrtk'll  t«.rrciri  at  to  -*  ti « 
basis  of  scan  and  azimuth  angles  received  from  the  rig-operated  real  antenna.  According 
to  this  range  a  delay  generator  is  remotely  controlled,  simulating  the  pulse  timing  for 
the  radar.  Fig  3  shows  the  comparison  of  a  real  flight  path  and  a  rig-simulated  one 
under  the  same  conditions.  The  flight  data  was  available  via  magnetic  tapes  recorded  by 
flight  test  equipment.  Derived  from  these  a  two  dimensional  actual  overflown  terrain  was 
reconstructed  by  subtracting  the  measured  radar  altimeter  height  from  the  corrected 
barometric  height.  This  terrain  was  fed  into  the  simulation  and  again  "overflown"  with 
the  rigs.  The  small  mismatch  between  the  flight  paths  is  within  acceptable  tolerances. 
Thus  the  built  up  hardware  in  the  loop  simulation  gives  significant  results  for  failure 
eorrsegurfreo  and  pt-tfutnwriCe  rests. 

4.  TEST  CONCEPTS  FOR  FUTURE  AVIONIC/WEAPON  SYSTEMS 

Basicly  the  Tornado  test  concept  came  up  to  the  expectations,  however,  same  points 
we' learnt  are  noteworthy  and  should  be  taken  into  consideration  for  future  developments. 

(a)  Well  equipped  test  rigs  comprising  as  many  as  possible  of  the  relevant  aircraft 
systems  reduce  development  time,  cost  and  potential  risk.  Such  a  rig  should  have  a 
modular  structure  with  growth  potential  to  support  all  phases  of  development  in¬ 
cluding  upgrade s/mod if ications  during  the  in  service  phase  of  the  flying  weapon 
system.  These  tasks  are  only  supported  effectively  if  the  ground  test  support  and 
simulation  tools  share  attributes  mentioned  in  the  following  two  points. 

(b)  A  homogeneous  support  software/hardware  system  should  be  used  for  testing  the 
flight  software,  integrating  the  hardware  and  preparing/evaluating  data  from  flight 
tests.  It  should  be  connected  to  a  data  base  of  the  avionic/weapon  system  which  is 
common  to  all  activities.  This  data  base  should  be  defined  and  implemented  as  early 
as  possible  in  the  development  phase,  thereby  enabling  configuration  and  compati¬ 
bility  control,  and  so  eliminating  a  main  error  source. 

(c)  Software  modifications,  i.  e.  fault  corrections,  upgrades  and  adaptations  to  system 
changes,  are  eased  dramatically  if  a  relevant  and  sufficient  documentation  exists. 
The  creation  of  effective  documentation  is  supported,  if  a  modern  computer  aided 
software  development  tool  and,  if  possible,  a  high  order  programming  language  is 
used. 

(d)  For  economic  reasons  it  is  necessary  to  provide  a  wide  spectrum  of  simulation-, 
stimulation  and  substitution  facilities.  The  most  powerful  configuration  is  requi¬ 
red  rarely,  the  less  complex  ones  more  frequently. 

(e)  The  avionic  and  weapon  systems  shall  provide  a  wide  access  to  internal  data  to  in¬ 
crease  the  testability.  For  rig  testing  avionic/weapon  units  should  be  available 
allowing  a  replacement  of  processor-chips  by  connections  to  external  real  time 
simulators  (emulators). 

The  following  brief  summary  describes  a  future  levelled  test  concept. 

Level  1:  The  software  development  for  the  mission  computer  and  the  test  support 
tools  is  performed  on  a  host  by  means  of  computer  aided  tools  and  by  employing  a  high 
order  programming  language.  A  data  Lase  describing  the  software  modalts  and  their  inter 
faces  is  installed.  This  data  base  has  sufficient  growth  potential  and  is  common  to  all 
development  tools  and  phases.  The  software  test  is  carried  out  by  using  emulator  devices 
for  the  target  computer  with  sophisticated  trace  and  fault  detection  capabilities. 
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Level  2:  The  basic  integration  of  equipments  as  well  as  the  hardware/ software  inte¬ 
gration  is  performed  on  a  rig,  which  has  a  structure  and  a  growth  potential  allowing  an 
upgrade  to  the  level  4  without  redesign. 

Level  3:  Flying  test  bed  investigations  can  be  onmitted  generally  but  may  be  useful 
in  special  cases,  provided  the  characteristics  of  carrier  aircraft  sufficiently  resemble 
the  aircraft  under  development. 

Level  4:  System  integration,  validation  and  performance  trial  are  carried  out  as 
far  as  possible  on  a  well  equipped  rig  facility  comparable  to  the  one  presented  in  this 
paper.  This  level  is  the  focal  point  of  all  test  activities.  The  general  intention  is  to 
detect  and  correct  all  errors  and  specification  mismatches  before  entering  flight  tests. 

Level  5:  Flight  test  on  prototypes  for  final  performance  trials  only. 


Special  to  Type  Test  Equipment 
with  Front 

end 


Computer  Aided 
Measurement  &  Simulation 
Facilities 


(1) 


(2) 


Figure  1:  Structure  of  the  Avionic/Weapon  Integration  Facility 
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DISCUSSION 


R.Cope,  UK 

You  claimed  that  in  IDAS  the  test  definition  is  in  plain  English.  Do  you  mean  that  literally  or  in  a  lexical  sense 
only?  Perhaps  you  could  spend  some  words  on  the  semantic  and  syntactical  analysis? 

Author’s  Reply 

The  communication  between  IDAS  and  the  user  is  performed  interactively  via  video  terminals.  The  engineer 
specifies  his  test  by  answering  successive  questions  generated  by  the  system  in  direct  readable  English.  In  most  cases 
he  has  to  make  a  choice  between  actual  possibilities  presented  in  tables  on  display.  On  request  additional  “help”- 
information  is  available. 

The  system  guided  specification  of  a  test  is  started  at  a  common  level  and  is  particularized  step  by  step.  The 
compatibility  of  every  input  is  checked  with  respect  to  the  structure  of  the  actual  test  as  far  as  already  known  to  the 
system. 

By  this  way  tests  can  be  defined  without  a  knowledge  of  a  specific  programming  language  like  PASCAL,  BASIC  or 
ASSEMBLER.  Since  the  dialogue  is  guided  and  limited  by  the  system,  an  analysis  of  the  free  language  is  not 
necessary  and  of  course  not  part  of  the  system. 


R.Cope,  UK 

The  necessity  to  input  such  detailed  information  as  channel  numbers  implies  that  the  tester  must  have  a  detailed 
knowledge  of  the  avionic  system  although  you  emphasized  during  your  paper  that  the  Avionics  Data  File  contained 
all  such  detailed  configuration  data. 

Author’s  Reply 

The  channel  number  mentioned  is  a  pure  key  enabling  an  automatic  access  to  information  stored  ill  the  Avionic  Data 
File.  This  key  can  be  found  easily  in  a  short  form  directory  on  basis  of  device  names  like  IN  or  ADC.  A  detailed 
knowledge  of  the  avionic  system  is  not  required. 


R.A.C.Smith,  UK 

When  the  rig  is  being  operated  in  its  fully  integrated  state,  i.e.  Flight  Controls  Avionic,  etc.  is  it  necessary  to  use 
actual  Aircrew  to  fly  the  rig  or  is  this  task  within  the  scope  of  the  rig  test  engineers? 

Author's  Reply 

The  rig-“flights”  are  guided  and  controlled  by  test  engineers  with  limited  experience  in  flying  airplanes.  Only  in  very 
special  cases  are  actual  Tornado  aircrews  involved. 


R.Davies.  UK 

How  in  rig  evaluation  of  operational  scenarios  do  you  simulate  the  different  levels  of  crew  experience  in  the  tri- 
national  Tornado  programme?  In  the  specific  case  of  the  West  German  Marineflieger  and  the  Italian  Aeronautica 
Militare  neither  had  Air  Navigator/Weapon  System  Operators  suitably  experienced  as  rear  crew  members  prior  to 
the  Tornado  acquisition,  to  fly  with  their  F-  l  04  experienced  pilots.  Their  level  of  operational  experience  must 
therefore  be  lower  than  the  Luftwaffe  or  RAF  Tornado  crews  and  this  must  affect  the  human  factors  aspect  of  rig 
work. 

Author's  Reply 

The  rig  was  mainly  used  for  the  initial  avionic  development  and  system  integration.  Up  to  now  human  factors  were 
investigated  in  special  cases  only,  e.g.  concerning  the  effectiveness  of  warnings  for  terrain  following  flights. 

If  evaluation  of  operational  scenarios  are  to  be  performed  as  a  future  task  for  the  rig  and  the  connectable 
simulations,  the  different  levels  of  crew  experiences  must  be  taken  into  consideration. 
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HARDWARE-IN-THE-LOOP  SIMULATION  TECHNIQUES  USED  IN  THE  DEVELOPMENT 
OF  THE  SEA  HARRIER  AVIONIC  SYSTEM 


by 

M.Mansell,  W.J.Quinn,  C.J.Smith 
British  Aerospace  Public  Limited  Company, 
Kingston/Brough  Division, 
Kingston-upon-Thames, 

Surrey 

UK 


Abstract: 


r-y  W  .fp-lir  1/  "r*/  . 


The  use  of  simulstion  utilising£airborne  hardware  in  the  loop  during  the 
development  of  avionic  systems  is  now  a  well  established  technique  used  by 
airframe  and  weapon  system  contractors.  However^  each  new  weapon  system 
produces  a  different  set  of  problems  that  usually  requires  a  change  of 
technique  in  order  to  satisfy  Sfche^test  requirements  for  the  system.  This 
paper  gives  a  brief  overview  of  the  Sea  Harrier  avionic  system  and 
describes  the  techniques  used  by  British  Aerospace  in  the  development  of 
this  system.  Descriptions  of  the  special-to-type  Interfaces  required  to 
drive  the  forward  looking  radar,  navigation  system,  automatic  flight 
control  and  HUD/weapon  aiming  computer  are  given,  '■re along  with  some 
specific  development  problems  that  were  overcome  using  the  techniques 
described. 


2.  Introduction 

The  Sea  Harrier  V/STOL  aircraft  avionic  system  was  oonflgured  for  single  sest 
operation  at  sea  to  assist  the  pilot  in  the  detection.  Identification, 
acquisition  snd  delivery  of  a  variety  of  weapons  agsinst  airborne  or  surface 
targets  using  new  sensors  and  a  combined  computlng/dlsplsy  system.  The  task  of 
British  Aerospace,  ss  weapon  system  contractor,  was  to  ensure  this  hardware  and 
assoolsted  software  wss  tested,  validated  and  integrated  into  the  aircraft  in 
an  efficient  snd  effective  manner.  This  wss  schieved  by  BAe,  in  stages  ss 
follows: 


a)  Mathematical  Modelling 

A  full  mathematical  model  of  the  aircraft  and  its  weapon  system  wss 
developed  on  the  simulator  looated  st  the  British  Aerospace  - 
Hatfield  Division.  Use  of  representative  flight  hardware  was 
restricted  to  cockpit  controls  only  -  sll  systems  being  emulated  or 
built  using  speoi>Dl  to  type  hardware.  This  modelling  sotivity,  being 
ahead  of  the  main  hardware/softwsre  development,  achieved  the 
following: 

o  Good  cockpit  ergonomio  design. 

o  Development  of  new  air-to-slr  weapon  aiming  and  Interception 
solutions . 

o  Development  of  head  up  snd  head  down  display  symbology. 

o  Development  of  landing  guidance  laws  and  techniques. 

o  Development  of  loft  snd  sir  to  ground  bombing  displays  snd 
solutions. 

b)  Ground  Testing 

Ground  testing  of  the  weapon  system  was  conducted ,  as  described  in 
this  paper,  at  the  flight  test  airfield  at  British  Aerospace, 
Dunsfold,  Surrey. 
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Flight  Testing 


Initial  flight  development  of  the  weapon  system  was  carried  out  using 
a  two  seater  Hunter  T  HK  8M  aircraft  fitted  with  a  full  airborne 
instrumentation  system.  Final  weapon  system  proving  was  then  carried 
in  the  Sea  Harrier. 


3.  Description  of  Sea  Harrier  FRS  Mk  1  Avionic  System 

The  Sea  Harrier  FfiS  Hk  1  (Fighter,  Reconnaisance  and  Strike)  aircraft  programme 
was  approved  in  mid  1975  and  whilst  90)  of  the  airframe,  power  plant  and 
mechanical  systems  were  common  with  the  earlier  Royal  Air  Force  Harrier  the 
avionics  (designated  the  navigation/attack  system)  was  about  90)  new.  Since 
the  prime  role  of  the  Sea  Harrier  was  as  a  fighter/interceptor  the 
navigation/attack  system  was  configured  to  satisfy  this  air-to-air  requirement. 
However  it  had  also  to  provide  a  good  air-to-ground  and  air-to-sea  surface 
weapon  delivery  capability  whilst  being  able  to  operate  autonomousl.  at  sea. 

The  essential  features  of  the  navigation/attack  system  are  shown  in  Figure  1 
and  comprises  the  following  sub-system:- 

o  Head  up  display  and  weapon  aiming  computer  (HUD/WAC). 

o  Navigation,  heading  and  attitude  reference  system  (NAVHARS) 

o  Radar 

o  Doppler  radar 

o  Air  data  system  (ADS) 

o  Tacan 

o  Compass  system 

o  Pilot's  display  recorder  (PDR) 

The  following  sub-systems  are  associated  with  the  navigation/attack  system  but 
are  regarded  as  peripheral  equipment:- 

o  UHF  homing 

o  Radar  altimeter 

o  IFF 

o  Armament  Control 

o  Automatic  flight  control 

o  Pilot  Static  system 

o  Head  down  instruments 

o  Fuel  system  indication 

o  Radar  warning  receiver 

o  Microwave  aircraft  digital  guidance  equipment  (MADGE) 

The  radar,  HUD/WAC  and  NAVHARS  systems  are  Interfaced  via  64  KHz  serial  digital 
data  links  with  the  other  sub-systems  retaining  their  conventional  analogue  and 
discrete  interfaces  (Figure  1). 


3. 1  Head  Up  Display  and  Weapon  Aiming  Computer 

The  HUDWAC  is  the  central  processor  and  symbol  generator  system  and  is  built  by 
Smiths  Industries  Ltd.  It  comprises  three  units: 

o  Pilots  display  unit 
o  Weapon  aiming  computer/electronics  unit 

o  Control  Panel 

The  operational  flight  software  was  supplied  by  Smiths  Industries  Ltd  and 
written  in  the  UK  standard  language  -  CORAL  66. 

The  salient  features  of  the  weapon  aiming  computer  are  summarised  below: 

o  Notation  General  purpose,  16  bit, 

fractional,  fixed  point,  double 
precision,  two's  complement. 

o  Storage  32K  read/write  core  plus  8K  read 

only  PROM. 

o  Instruction  execution  rate  475,000  operations/see  (depending 

upon  Instruction  mix). 

o  No  of  instructlona  59  microprogram  controlled, 

o  Interrupts  Eight  level  vectored  priority. 
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o  I/O 


Program  controlled 
Direct  Memory  Access 


o  Serial  I/O 


3  serial  data  links  in  and  3  out. 


o  Discrete  I/O 
o  Analogue  I/O 

o  Software 


48  input  discretes 
14  output  discretes 

Inputs  :  48  d.c. 

4  synchro 
1  resolver 
Outputs:  8  d.c. 

Coral  66  4-  assembler 


The  HUD/WAC  provides  the  following  facilities  to  the  pilot: 

1.  Display  of  aircraft  attitude  and  heading  and  vertical  velocity. 

2.  Display  of  other  flight  information  by  pilot  selection  e.g.  IAS, 
angle  of  attack  and  sideslip. 

3.  Display  of  navigation  aids  -  UHF  Homing  and  TACAN. 

4.  Output  of  flight  information  to  radar  display  in  a  video  format. 

5.  Computation  and  display  of  all  air-to-ground  weapon  aiming. 

6.  Solution  of  air-to-air  weapon  aiming  equations. 

7.  Display  of  Sidewinder  firing  solution. 

8.  Pointing  of  radar  antenna  in  some  weapon  aiming  modes. 

9.  Manual  or  automatic  release  of  weapons. 

10.  An  integral  independent  standby  sight. 

The  operational  modes  available  are  shown  in  Table  I  and  are  selected  by  a 
combination  of  controls  on  the  HUD/WAC  control  panel,  missile  control 
panel  and  armament  control  system. 

TABLE  1 


Mode 

V/STOl 

Bearing 

launoh 

General 


Description 

Display  of  relevant  flight  Information  during  vertical 
and  short  take  off  and  landing  phase. 

Used  to  establish  aocurate  heading  datum  for  preflight 
insertion  into  NAVKARS  system. 

Used  during  ship  ramp  launch  of  aircraft. 

General  navigation  mode. 


Air-to-Air  Provides  a  comprehensive  set  of  gun  and  missile 

computations,  control  and  displays  dependent  upon 
weapon  aeleotion  and  radar  status. 

Vlsldent  Provides  steering  information  to  enable  targets  to  be 

identified  at  dose  range  at  night  or  poor  visibility. 

Alr-to-G round  Manual  release  of  guna,  rockets  or  bomba.  Automatic 

release  of  bombs. 


PIA  Pilot  Interpretsted  Approach  -  provides  guidance  in 

asumlth  and  elevation  during  landing  phase  using 
navigation,  radar  or  landing  aid  data  (MADGE). 

REV 


Reversionary  navigation  and  weapon  aiming  display 
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3.2  Navigation,  Heading  and  Attitude  Reference  System 

The  NAVHARS  system  provides  navigational,  heading  and  attitude  information  to 
the  pilot,  stabilisation  of  the  forward  looking  radar  antenna,  ground 
stabilisation  of  a  radar  target  marker  and  velocity  information  for  weapon 
aiming  computing.  It  comprises  the  following  three  units  ar.d  is  manufactured 
by  Ferranti  Ltd: 

o  Platform  navigational  (PN) 
o  Flectronics  unit,  navigation  (EUN) 
o  Display  navigational  control  (DNC) 


The  NAVHARS  requires  information  from  other  systems  in  order  to  fulfil  its 
functions  and  together  with  the  following  forms  the  overall  navigation  system: 

o  Air  data  computer  providing  TAS  and  barometric  height. 

o  Doppler  radar  providing  doppler  velocity  along  and  across  heading  and 
perpendicular  to  the  aerial. 

o  Forward  looking  radar  providing  radar  target  marker  range  and  bearing, 
antenna  elevation  angle  and  radar  hand  controller  outputs. 

o  Tacan  providing  range  and  bearing  to  selected  station. 

o  Fuel  system  providing  fuel  contents  and  fuel  flow  rate. 

o  Flux  valve  providing  magnetic  heading. 


3.2.1  System  Operation 

The  NAVHARS  system  uat-  designed  to  operate  autonomously  at  sea  and  does 

not  require  a  data  link  from  the  ships  navigation  system  to  the  aircraft. 

All  data  required  for  alignment  can  be  inserted  by  the  pilot  and  comprises 
ships  speed  and  heading,  present  position  and  sea  motion.  The  platform 
can  be  operated  in  a  magnetic  or  memorised  heading  mode  with  selection  of 
the  mode  being  at  the  pilot's  discretion.  Alignments  at  sea  are  achieved 
using  the  memorised  mode  and  can  be  accomplished  along  or  offset  from 
ships  heading. 

The  NAVHARS  operates  in  the  following  navigate  modes: 

a)  Doppler  damped  -  a  doppler/ inertial  mix  mode. 

b)  True  air  speed  damped  -  an  inertial  damped  with  TAS  mode. 

c)  Pure  inertial  -  a  Schuler  tuned  inertial  loop  mode. 

d)  Damped  inertial  -  this  mode  is  automatically  entered  following 
NAVHARS  alignment  but  before  doppler  or  TAS  velocities  are 
available. 

The  doppler  velocity  damped  mode  is  the  primary  mode  but  under  some 
conditions,  particularly  during  manouevres,  doppler  velocities  are  not 
available.  At  these  times  the  system  switches  automatically  to  an 
inertial  mode  of  operation  and  if  the  doppler  remains  invalid  for  more 
than  two  minutes  then,  if  TAS  is  available,  the  system  will  switch  to  a 
TAS  damped  mode  with  stored  wind  as  a  reference.  If  TAS  is  invalid  the 
system  will  revert  to  a  pure  inertial  mode.  The  system  will  revert  to 
doppler  damped  any  time  doppler  becomes  valid. 

Table  II  shows  the  facilities  provided  by  the  NAVHARS. 
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TABLE  II 


Facility 

1 .  Insertion  and  Display 
of  Destinations 

2.  DNC  Display 

3.  Position  updating  (fixing) 


4.  Insertion  of  Destinations 


5.  Change  of  grid  origin 

6.  FROT 


Function 


Storage  and  display  of  ten 
destinations  in  either  Lat/Long  or 
grid  co-ordinates. 

Display  and  computation  of  flight 
and  navigation  information. 

Updating  of  position  information  in 
navigate  mode  as  follows: 


a) 

On-top  planned  or 
fix. 

unplanned 

b) 

Tacan  fix 

c) 

Radar  display  fix 

d) 

Radar  locked  target 

fix 

Insertion,  in  flight,  of  future 
destinations  without  direct 
knowledge  of  their  co-ordinates  as 
follows: 

a)  Present  position  insertion  as  a 
destination. 

b)  Radar  display  insertion  as  a 
destination. 

c)  Locked  target  insertion  as  a 
destination. 

Change  of  grid  origin,  without 
direct  knowledge  of  the  Lat/Long 
co-ordinates  of  the  new  grid 
origin. 

Computation  of  Fuel  Remaining  On 
Task. 


3.3  Radar 


The  Blue  Fox  radar  is  a  lightweight  I-band  search  radar  used  for  the 
detection  and  tracking  of  airborne  and  surface  targets  and  for  the 
interrogation  of  transponder  equipped  aircraft  or  surface  vessels.  The 
radar  comprises  nine  line  replaceable  units  (LRU's)  five  of  which  are 
located  in  the  nose  of  the  aircraft  and  four  in  the  cockpit  and  is  built 
by  Ferranti  Ltd. 

The  radar  provides  the  following  functions: 

o  A  blind  search  about  aircraft  heading  against  airborne  or 

surface  targets  using  a  normal  head  down  display.  Sector  PPI  or 
B  Scan  displays  oan  be  selected  by  the  pilot. 

o  A  faolllty  to  deteot  small  airborne  and  surface  targets. 

o  A  means  of  traoking  a  seleoted  target  with  range  and  bearing 

displayed. 

o  A  means  of  traoking  JaMing  targets. 

o  Tracking  of  targets  aoquired  visually  on  the  radar  boresight. 

o  Deteotlon  of  friendly  targets  by  interrogation  of  their 

transponders. 

o  An  interfaoe  with  the  navigation/attaok  system. 
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3.4  Automatic  Flight  Control  System  (AFCS) 

The  AFCS  is  an  integrated  autostabilisation  (autostab)  and  autopilot 
flight  control  system,  provided  to  assist  the  pilot  in  maintaining 
stability  during  jetborne  and  transitional  flight  and  to  control  the 
flight  path  in  wingborne  flight  without  pilot  assistance.  The  necessary 
pitch  and  roll  demands  on  the  control  surfaces  and/or  reaction  controls 
share  auto  control  channels  common  to  both  autostab  and  autopilot.  A 
separate  yaw  autocontrol  channel  is  peculiar  to  autostab.  The  AFCS  is 
built  by  Marconi  Avionics  Ltd. 
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3.4.1  Autostabiliser  Facilities 

o  Operates  over  speed  range  0  -  250  knots. 

o  Rate  gyro  control  is  provided  in  pitch  and  roll  axes. 

o  Yaw  channel  control  is  provided  by  lateral  acceleration,  yaw 
rate  and  lateral  stick  position. 

3.4.2  Autopilot  Facilities 

o  Operates  at  speeds  >250  knots, 
o  Provides  the  following  autopilot  modes: 

a)  Elevation  and  bank  attitude  hold. 

b)  Heading  hold 

c)  Barometric  height  hold 


4.  Description  of  Sea  Harrier  Avionic  Test  Facility 

The  Sea  Harrier  avionic  system  facility  comprises  three  test  sections  as 
follows: 

1)  Vendor  test  equipment  -  used  for  acceptance  and  specification 
compliance  testing. 

2)  Integration  rig  -  used  for  quasi-static  integration  checks  with 
three  test  benches  for  radar,  NAVHARS/doppler/compass  system  and 
HUDWAC.  These  portable  benches  are  also  capable  of  performing 
equipment  serviceability  checks  and  were  also  used  to  support 
development  flight  trials  at  sea  on  HMS  Hermes  and  HMS  Invincible. 

3)  Dynamic  development  rig  (DDR)  -  used  for: 

a)  Total  avionic  system  integration. 

b)  To  provide  a  dynamic  test  facility  by  driving  the 

navigation/attack  system  via  a  VAX  11/780  and  floating  point 
system  AD  120  array  processor  for  hardware  and  HUDWAC  software 
test  and  validation. 

c)  Development  of  autopilot  control  laws. 


4.1  Dynamic  Development  Rig 

The  prime  purpose  of  the  DDR  is  to  drive  avionic  navigation/attack  hardware 
in-the-loop  during  Sea  Harrier  attack  profiles.  The  philosophy  adopted  in 
designing  the  DDR  was  to  include,  where  feasible  and  cost  effective,  all 
weapon  system  components.  It  was  however  decided  not  to  include  the  basic 
aircraft  sensors  such  as  attitude  and  rate  gyros  and  pressure  sensors  which 
would  involve  the  use  of  expensive  and  unwieldy  high  bandwidth  rate  tables  or 
pneumatic  equipment.  The  omitted  sensor  signals  were  generated  by  the 

simulator  computer  and  injected,  via  dedicated  interfaces,  into  the 

appropriate  system,  so  as  to  minimise  the  hardware  not  included  in  the  loop, 
as  described  in  detail  below.  The  DDR  comprises  four  main  sections. 

Figure  2  showa  the  main  signal  flow  for  the  DDR  between  the  simulator  interface 
and  the  navigation/attack  system. 
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4.1.1  Hardware  Rig  Modules 

Eight  rig  modules  were  built  with  the  following  functions: 

Hodule  Function 

1  Radar 

2  HUDWAC 

3  NAVHARS/doppler /compass  system 

4  Airborne  Instrumentation 

5  AFCS,  ADC  and  radar  altimeter 

6  Armaments 

7  Radio  communication,  TACAN,  ESM 

8  Missile  systems 

Each  module  with  its  equipment  may  be  functioned  independently  of  other 
modules  either  a)  statically  using  analogue  inputs  from  a  static 
simulation  panel  and  digital  inputs  via  a  data  link  word  generator  or  b) 
dynamically  using  the  VAX  11/780.  In  this  way  avionic  equipments  not 
available  could  be  directly  emulated. 


4.1.2  The  Simulator 

This  comprised  an  outside  world  display  and  a  cockpit  fitted  with  the 
following  airborne  avionic  cockpit  equipment. 

o  HUD  and  control  panel 

o  DNC 

o  Radar  display  and  controls 
o  Flying  controls  and  AFCS  control  panel 


4.1.3  The  Central  Computer 


Figure  (3)  is  a  block  diagram  of  the  computer  equipment  in  the  Sea 
Harrier  Dynamic  development  facility.  It  comprises  a  DEC  VAX-1 1/780 
computer  system  and  standard  peripheral  equipment,  operating  system  and 
language  processors.  A  DEC  PDP-11/10  computer  is  used  to  drive  a 
monochrome  cursive  outside  world  display,  and  a  very  fast  floating  point 
array  processor  from  Floating  Point  Systems  Ltd  is  used  to  host  the 
aircraft  and  equipment  models.  Additionally,  a  series  of  standard 
interface  cards  are  used  to  drive  the  purpose  built  avionic  equipment 
simulators.  This  facility  is  used  for  software  development,  data 
processing,  compilation/assembly  of  airborne  MAC  programs  and  simulation 
activities.  The  equipment  comprises; 

o  (  1)  DEC  VAX-1 1/780  computer 

(2.5  Mbytes  memory  +  floating  point  hardware) 

o  (  2)  67  Mbyte  disk  drives 

o  (  1)  256  Mbyte  disk  drives 

o  (  2)  magnetic  tape  drives 

o  (32)  analogue-to-digital  converter  channels 


o  (12)  digital-to-analogue  converter  channels 

o  (1)  printer 

o  (  2)  printer /plotters  (electrostatic) 

o  (1)  flat-bed  plotter 

o  (20)  CRT/keyboard  terminals 

o  (1)  communications  sub-system  (networking) 

o  (1)  FPS  AP-120B  floating  point  array  processor 

(8K  main  data  memory  +  4K  program  source  memory) 

o  (1)  DEC  PDP  11/10  computer  (6K  words  memory) 
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The  following  software  is  currently  in  use  in  the  faeility:- 
System  Software 

o  VAX/VMS  V3.1  Operating  system 

o  MACRO-32  V3.0  Assembler 

o  VAX-11  FORTRAN  V3.1  Compiler 

o  VAX- 11  DATATRIEVE 

o  VAX- 11  COMMON  DATA  DICTIONARY 

o  EDT  Screen  editor 

o  FPS  APEX  array  processor  executive 

o  TOAST  (AP  software  development  system) 
o  Plotter  support  packages 

o  Graphics  terminal  support  package 


Avionic  Support  Software 

o  Sea  Harrier  small  perturbation  model 

o  Sea  Harrier  low  speed  model 

(including  full  aerodynamics,  hover  dynamics  and  engine 
effects) 

o  Avionic  equipment  models 

o  Standard  atmosphere  model 
o  Stores  ballistics  models 

o  Target  control  system 

o  Smith's  Industries  RA 22  CORAL  cross-compiler 
o  Smith's  Industries  SICOL  assebler/linker 

o  General  plotting  package 


4.1.4  Hardware  Interfacing 

In  order  to  drive  the  navigation/attack  system  hardware  in  a  dynamic  mode 
special  to  type  interfaces  between  the  VAX-1 1/780  and  the  airborne 
equipment  were  developed.  The  primary  interfaces  are  described  as 
follows. 


4. 1.4.1  Radar  Interfaces 


The  radar  angles  and  range  interfaces  are  shown  in  Figure  4A  and  4B 
respectively.  The  VAX  11/780  emulates  a  target  position  which  is 
differenced  with  the  antenna  position  from  the  radar.  The 
difference  is  the  position  error  which  is  compared  with  the  beam 
width  and  if  within  activates  a  gate  latch  which  allows  the  radar  to 
lock  onto  the  target.  The  position  errors  are  sent  to  the  radar 
which  allows  the  antenna  to  be  driven  to  the  simulated  target 
position.  Range  is  generated  via  VAX  11/780  control  of  the  timer 
shown  in  Figure  4B.  Radome  aberration  effects  are  emulated  by  adding 
the  appropriate  aberration  angle  to  the  target  position. 


4. 1.4. 2  NAVHARS  Interface 


The  NAVHARS  velocity  interface  is  shown  in  Figure  5A.  The  VAX 
11/780  generates  a  demanded  velocity  which  is  differenced  with  the 
actual  velocity  from  the  EUN.  The  error  velocity  is  converted  from 
a  digital  to  analogue  signal,  multiplied  by  gain  K  and  converted  to 
a  demanded  acceleration.  The  gain  K  is  set  such  that  the  digital 
loop  is  deadbeat  i.e.  the  velocity  error  is  driven  to  zero  in  one 
loop  sample  period.  This  is  differenced  with  a  torqueing  current 
equivalent  to  the  actual  acceleration.  The  resultant  signal  is  thsn 
passed  through  a  low  pass  filter  and  modulated  to  become  the 
acceleration  error  fed  to  the  EUN.  Velocities  are  generated  by 
integration  within  the  EUN.  Three  identical  circuits  are  used  for 
Vx,  Vy  and  Vz,  The  synohro  angles  are  generated  via  digital/synchro 
converters  as  shown  in  Figure  5B. 


4 . 1 . 4 . 3  Doppler  Interface 

The  doppler  interface  is  shown  in  Figure  6.  the  VAX  11/780 
generates  demanded  doppler  velocities  to  a  variable  frequency  sine 
wave  oscillator.  This  oscillator  produces  the  doppler  frequencies 
appropriate  to  the  demanded  velocities  and  are  fed  to  the  spectrum 
generator  which  adds  to  each  doppler  frequency  a  noise  spectrum. 
This  spectrum  has  a  frequency  bandwidth  that  is  automatically 
adjusted  for  speed  variation.  The  final  simulated  doppler  velocity 
signals  are  then  fed  to  the  IF  stage  of  the  doppler. 

4. 1.4. 4  HUDWAC  Interface 

The  HUDWAC  and  ADC  interfaces  are  shown  together  in  Figure  7  since 
these  two  units  were  generally  operated  together  during  HUDWAC 
software  testing  and  validation.  This  ensured  that  ADC  lags  (with 
the  exception  of  the  pilot  static  system  lags)  were  always  present 
by  virtue  of  using  the  flight  hardware.  The  ADC  interfaces  are 
straight  voltage  representation  of  pitot  and  pitot-static  pressures 
driving  servo  controller  force  balance  units.  The  NAVHARS  and  radar 
serial  data  links  were  generally  provided  by  flight  hardware  driven 
by  the  VAX  11/780  as  described  above.  However  these  data  links 
could  be  provided  via  equipment  emulations  within  the  VAX  11/780  and 
a  parallel  to  serial  interface.  This  proved  to  be  an  extremely 
useful  rig  facility  particularly  during  development  of  air-to-air 
interception  course  computing  and  missile  launch  success  zone 
software. 


Dynamic  Test  Facility  -  Test  Experience  and  Limitations 


5.1  The  dynamic  development  facility  has  proved  useful  for  both  early 
evaluation  of  weapon  system  problem  areas  and  new  system  development  and  has 
significantly  reduced  the  total  flying  hours  required  on  the  development 
programme.  Two  specific  development  areas  that  illustrate  the  flexibility  and 
uses  of  the  facility  are  described  briefly  below: 


Autopilot  Height  Hold  Limit  Cycle 


During  initial  autopilot  flying  intermittent  limit  cycling  of  an  unpredicted 
nature  occured  in  height  hold.  The  frequency  of  the  oscillations  was  higher 
than  anticipated,  resulting  in  unacceptable  peak  'g'  levels  as  seen  by  the 
pilot,  and  was  worse  at  altitude.  This  type  of  limit  cycling  had  not  been 
seen  during  the  hardware-in-the-loop  simulation  that  had  been  carried  out 
before  flight  and  It  was  suspected  that  the  cause  was  an  intermitent 
non-linearity  which  was  more  complex  than  the  anticipated  Air  Data  Computer 
(ADC)  dead-space.  This  suspicion  was  confirmed  by  running  the  simulation  as 
shown  in  Figure  8  with  several  different  ADC's  and  by  operating  the  system  at 
different  engage  heights  where  the  limit  cycle  observed  in  flight  again 
occured  intermittantly. 


Flight  Results 


A  typical  limit  cycle  is  shown  in  Figure  9.  The  limit  cycle  has  a  period 
of  some  10  seconds  and  an  amplitude  in  height  of  approximately  20  feet, 
the  resulting  normal  acceleration  has  a  peak  amplitude  of  approximately 
0.2g.  The  period  and  amplitude  of  the  limit  cycles  were  found  to  vary 
with  height  and  with  the  particular  ADC  fitted.  A  period  of 
approximately  10  seconds  was,  however,  typical  of  the  altitude. 


5.2.2  Simulation 

The  height  limit  cycle  was  reproduced  on  the  Dunsfcld  DDR  with  the 
hardware  ADC  and  autopilot  in  the  loop.  Although  the  limit  cycling  is 
less  smooth,  due  to  lack  of  aircraft  vibration  the  simulator  and  flight 
results  compare  very  well  with  respect  to  limit  cycle  frequency  (See 
Figure  9). 

Simulator  studies  indicated  that  a  modification  to  the  height  control  law 
to  incorporation  a  complementary  mix  of  bare  height  and  height  rate  would 
prove  effective  in  curing  the  height  limit  oyole. 

An  autopilot  was  modified  to  include  the  proposed  solution  and  was  flight 
tested.  During  the  first,  and  subsequent  flight  tests  no  limit  cycling 
in  height  hold  was  observed  and  the  modification  was  inooporated,  without 
further  change,  in  production  autopilots. 


5.3  Advance  Radar  Tracking  System 


Development  work  is  at  present  being  carried  out  on  an  advanced  radar  tracking 
system  for  the  Sea  Harrier.  The  proposed  system  should  have  benefits  in  terms 
of  much  improved  estimates  of  a  targets  velocity  and  acceleration  and  an 
enhanced  ECM  capability.  A  sophisticated  system  of  this  type  would  normally 
require  many  flight  hours  to  optimise  the  system  equations.  It  is  however, 
hoped  to  minimise  this  time  by  means  of  employing  the  following  two  simulation 
methods:- 

(a)  VAX  11/780  Control  of  the  Blue  Fox  Radar 


The  Dynamic  Development  Rig  (DDR)  is  being  modified  to  allow  direct 
VAX  11/780  control  of  the  radar,  the  VAX  being  programmed  to 
simulate  the  weapon  aiming  computer  processing  and  radar  control 
functions.  The  proposed  VAX/Radar  simulation  is  shown  in  Figure 
10A.  A  simulation  of  this  type  is  attractive  for  several  reasons:- 

(i)  Simulation  results  involving  a  hardware  radar  will  be 
available  in  advance  of,  and  may  affect  the  contents  of,  the 
HUDWAC  software  package. 

(ii)  The  tracker  equations  will  be  programmed  in  a  high  level 

language  in  a  'user  friendly'  environment  i.e.  the  system 

modification  would  prove  far  simpler  than  the  production  of  a 
revised  HUDWAC  program. 

(iii)  The  use  of  real  targets,  either  'targets  of  opportunity'  or 

aircraft  briefed  to  perform  certain  manoeuvres  within  the  DDR 
radar  field  of  view,  would  allow  assessment  of  the  effect  of 
genuine  radar  noise  on  the  system. 

(iv)  It  is  intended  at  a  future  date  to  enhance  the  target 

simulation  to  include  ECH  effects. 


(b)  Full  Hardware-in-the-loop  Simulation 

The  second  phase  of  the  system  development  would  involve  a  fully 
integrated  weapon  system  as  shown  in  Figure  10B  and  would  comprise: 

(a)  Simulation  with  real  targets  with  the  NAVHARS  EU  and  PN  in  the 
loop,  i.e.  no  'aii craft'  manoeuvres. 

(b)  Simulation  with  synthetic  targets  and  with  the  NAVHARS  PN 
simulated  by  the  VAX  11/780. 

The  simulation  involving  real  targets  will  require  a  minor 
modification  to  the  HUDWAC  software,  such  that  the  corrections  for 
radome  aberration  are  zeroed,  as  the  DDR  radar  operates  without  a 
radome.  Aircraft  ground  tests  against  a  manoeuvring  target  would 
complete  the  pre-flight  testing  and,  when  compared  to  the  rig 
results,  would  indicate  any  problems  specific  to  the  aberration 
correction  software. 

This  simulation  will  enable  the  problems  associated  with  delayed 
sensor  data,  implicit  in  a  digital  data  stream  weapon  system  of  this 
type,  to  be  fully  investigated  before  flight. 


6.  CONCLUSIONS 


The  test  procedures  and  test  rig  configuration  using  flight  hardware  in  the 
loop  adopted  by  British  Aerospace  significantly  reduced  the  total  flying  hours 
required  during  the  Sea  Harrier  development  programme.  The  flexibility  built 
into  the  test  system  has  enabled  BAe  to  respond  quickly  to  problems  and 
changes  of  requirement  and  has  allowed  advanced  techniques  to  be  studies  and 
tested  without  msjor  rig  configuration  changes. 
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FIGURE  1 


BLOCK  DIAGRAM  OF  SEA  HARRIER  NAVIGATION/ATTACK  SYSTEM 
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FIGURE  5A.  VAX  1 1/700  TO  NAVHARS  -  VELOCITY  INTERFACE 


FIGURE  5&  VAX  11/780  TO  NAVHARS  INTERFACE  -  SYNCHRO  ANGLES 
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FIGURE  6.  VAX  11/780  TO  DOPPLER  RADAR  INTERFACE 


FIGURE  7.  VAX  11/780  TO  ADC  AND  HUDWAC  -  INTERFACES 
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FIGURE  8.  BLOCK  DIAGRAM  OF  A.F.OS.  TO  VAX  11/780  INTERFACE  ARRANGEMENT 
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FIGURE  9:  SEA  HAMXER  AUTOPILOT  -  HEIGHT  LIMIT  CYCLE 


^  ^  8  <>  0  0  <j  Qy 


W-i 


SIMULATION  REQUIREMENTS  TO  SUPPORT  THE  DEVELOPMENT  OF  A  FAULT 
TOLERANT  AVIONIC  SYSTEM 


J.  Shaw 

Northrop,  Corporation 
Aircraft  Division 
Hawthorne,  CA  90250 
USA 


ABSTRACT 


h  the  need  for  advanced  avionics  system  executives,  several  tools  are  essential 
aiding  the  avionics  system  software  engineer  with  the  design  and  development  of 
these  executives.  These  tools  should  provide  the  user  with  an  interactive  simulation 
^ for  the  development  of  fault  tolerant  avionic  systems  and  executives. 

t—?  This  paper  presents  the  Northrop  Avionics  simulation  package  which  &as  badrfy designed  to 
support  the  development  of  fault  tolerant  avionic  systems.  Described  is  the  Executive 
Support  System,  ESS,  package  which  is  presently  being  used  as  a  development,  test  and 
verification  tool  for  F-5G  and  F-18L  avionics  models.  ESS  provides  an  avionics  system 
designer  with  a  mechanism  for  developing  and  testing  several  avionic  core  configurations 
as  we ll  as-tdeve lofrj.vion ic  simulation  and  application  modules. 

ESS  consists 'of  an  interactive  user  interface  that  allows  the  user  to  configure  the 
core  avionics  system  as  desired.  Once  the  core  system  has  been  specified  the  user  is 
able  to  specify  whether  centralized  or  distributed  philosophies  are  to  be  used  in  the 
system  executive.  The  executive  consists  of  a  user  definable  scheduler,  system  monitof 
and  system  support  library.  Application  and  system  support  software  can  be  developed 
by  the  user  and  exercised  by  the  ESS.  In  this  way  the  ESS  can  be  easily  tailored  to 
various  applications  and  configurations.  Since  the  development  phase  of  any  system 
includes  debugging,  ESS  also  provides  the  user  with  Interactive  symbolic  debugging 
capabilities.  These  capabilities  allow  the  user  to  examine,  modify  and  monitor  all 
of  the  simulation  variables.  - - 


ESS  is  presently  being  enhanced  to  support  the  development  of  multiple  scheduling 
processing  elements,  this  will  allow  one  program  to  stimulate  multiple  airframes 
or  multiple  processing  elements  in  multiple  user  specifiable  cor. figurations. 


MODERN  AVIONICS  SYSTEM 
REQUIREMENTS 


•  FAULT  TOLERANT 

-  CENTRALIZED  OR  DISTRIBUTED  CONTROL 

-  REDUNDANT  RESOURCES 


•  INCREASED  THROUGHPUT/DISTRIBUTED  PROCESSING 


MODERN  AVIONICS  SYSTEM  SIMULATION 

REQUIREMENTS 


•  MODEL 

-  CENTRALIZED  CONTROL 

-  DISTRIBUTED  CONTROL 

-  REDUNDANT  RESOURCES 

-  COMMUNICATION  SCHEMES 

•  EVALUATE 

-  THROUGHPUT 

-  AVAILABILITY 

-  RELIABILITY 

•  ALLOW  FOR 

-  SYSTEM  DESIGN 

-  SYSTEM  ANALYSIS 

-  SYSTEM  IMPLEMENTATION 

•  OFP  DEVELOPMENT 

•  SYSTEM  INTEGRATION 

•  SYSTEM  TESTING  AND  VERIFICATION 
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MAJOR  FACILITY  SEGMENTS 


SIMULATION  SYSTEMS 
SOFTWARE  DEVELOPMENT  SYSTEM 
LRU  HOT  BENCHES 
DIGITAL  INTERFACE  TEST  SETS 
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SIMULATION  SYSTEMS 


SIMULATION  DEVELOPMENT  PACKAGE  (SIMPAC) 

•  GENERAL  PURPOSE  SIMULATION  SUPPORT  PACKAGE 

•  AID  USER  IN  THE 

-  DEVELOPMENT  OF  SIMULATION  OR  SUPPORT  MODULES 

-  DEBUGGING  OF  SIMULATION  OR  SUPPORT  MODULES 

-  DESIGNING  AND  CONFIGURING  AVIONICS  SYSTEMS 

-  DEVELOPMENT  AND  DEBUGGING  OF  HARDWARE  AND 
SYSTEM  TEST  SOFTWARE 

SIMULATION  SYSTEMS 


SIMPAC  CONSISTS  OF 

•  RELINK 

•  SCENARIO 

•  BUSMON 

•  VIEW 


I 
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RELINK 

•  BASIC  SIMULATION  CONFIGURATOR 

•  THE  USER  HAS  THE  FOLLOWING  CONFIGURATION  OPTIONS: 

-  SHAREABLE  IMAGES/SEGMENTS 

-  SHARED  MEMORY 

-  COCKPIT  SUPPORT 

-  GRAPHICS  SUPPORT 

-  BASELINED  GENERIC  MODEL  SUPPORT 

-  BASELINED  F-20  MODEL  SUPPORT 

-  BASELINED  F-18  MODEL  SUPPORT 

-  CUSTOM  USER  PROVIDED  SOFTWARE 

SIMPAC 


SCENARIO 

•  SCENARIO  IS  THE  INTERACTIVE  USER  INTERFACE  PORTION  OF  THE 
NORTHROP  SIMULATION  PACKAGE 

•  SCENARIO  WILL  ALLOW  A  USER  TO: 

-  SET  AND  EXAMINE  ANY  LOCAL  OR  GLOBAL  SIMULATION  VARIABLE 

-  SCHEDULE  APPLICATION  OR  AVIONICS  TASKS 

-  LOG  SIMULATION  LOCAL  OR  GLOBAL  DATA  IN  REAL  TIME 

-  MONITOR  INTERACTIVELY  SIMULATION  DATA 

-  RUN  TIME  CRITICAL  FUNCTIONS  IN  REAL-TIME 

-  INVOKE  AN  INTERACTIVE  SYMBOLIC  DEBUGGER 
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VIEW 

VIEW  IS  AN  INTERACTIVE  PROGRAM  THAT  WILL  ALLOW  A  USER  TO 
REDUCE  DATA  FILES  THAT  HAVE  BEEN  GENERATED  BY: 

•  SCENARIO:  SIMULATION  INTERNAL  DATA 

•  BUSMON:  MIL-STD  1553B  BUS  DATA 

•  1750  SUPPORT  HARDWARE:  INTERNAL  RECORDED  DATA 

SIMPAC 


VIEW 

VIEW  WILL  ALLOW  THE  USER  TO  DISPLAY  THE  DESIRED  DATA  IN 
VARIOUS  USER  DEFINABLE  FORMATS  ON  VARIOUS  OUTPUT  DEVICES 

•  THE  USER  MAY: 

-  PLOT  ONE  VARIABLE  AGAINST  ANOTHER 

-  OVERLAY  MULTIPLE  PLOTS 

-  LIST  DATA  IN  A  TABULAR  FORM 

-  GET  GRAPHICAL  REPRESENTATIONS  OF  1553B  BUS  UTILIZATION 

-  DUMP  SELECTED  1553B  DATA  IN  HEX  FORM  OR  ENGINEERING  UNITS 
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SOFTWARE  DEVELOPMENT  SYSTEM 


•  INTERFACED  TO  SEVERAL  1750  TEST  SETS  AND  STATIONS 

-  ALLOWS  DOWN  LOADING 

-  CENTRAL  CONTROL  OF  INDIVIDUAL  1750  TEST  STATIONS 

•  REMOTE  DEBUGGING 

•  REMOTE  EXECUTION 

SOFTWARE  DEVELOPMENT  SYSTEM 


THE  SOFTWARE  DEVELOPMENT  SYSTEM  CONSISTS  OF  SEVERAL  1750 
AND  JOVIAL  DEVELOPMENT  AND  SUPPORT  TOOLS: 

•  1750  ASSEMBLER 

•  1750  LINKER 

•  1750  COMPUTER  SIMULATOR 

•  1750  SYMBOLIC  DEBUGGER 

•  1750  FORMATTER 

•  (FUTURE  SUPPORT  OF  NEBULA) 

•  JOVIAL  COMPILER 

-  VAX  AND  1750  TARGETED 

•  JOVIAL  SYMBOLIC  DEBUGGER 

•  (FUTURE  SUPPORT  OF  ADA) 


NORTHROP  PROPRIETARY 
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1750  COMPUTER  SIMULATOR 

THE  ICS  IS  A  GENERAL  PURPOSE  1750A  INTERPRETIVE  COMPUTER 
SIMULATION  THAT  GIVES  THE  USER  THE  FOLLOWING  CAPABILITIES: 

•  DEFINE  BASIC  CONFIGURATION  OF  THE  SIMULATED  1750A 

•  LOAD  THE  LOAD  MODULES  INTO  THE  ICS 

•  SAVE  THE  STATE  OF  THE  ICS 

•  EXAMINE/SET  ALL  1750A  REGISTER  MEMORY  LOCATIONS  AND 
TRAP  LOCATIONS 

•  SET  AND  REMOVE  BREAK  POINTS 

•  GENERAL  CONTROL  OF  PROGRAM  EXECUTION 

•  DISASSEMBLY  OF  1750A  CODE 

1750  FORMATTER 


•  CREATES  VENDOR  SPECIFIC  LOAD  MODULES  FROM  THE 
OUTPUT  LOAD  MODULES  FROM  THE  1750  LINKER 

•  THE  LOAD  MODULE  IS  THEN  EASILY  TRANSFERABLE  TO 
THE  TEST  STATIONS 


1750  TEST  SETS  AND  STATIONS 


•  STATIONS  CONTAIN: 

-  1750  ASSEMBLERS 

-  1750  LINKERS 

-  SYMBOLIC  DEBUGGERS 

-  APPROPRIATE  1750  INTERFACE  HARDWARE 


LRU  HOT  BENCHES 


•  PROVIDE  LRU  POWER 

•  PROVIDE  PROPER  ELECTRICAL  STIMULATIONS 

•  INTERFACE  TO  THE  SIMULATION  OF  SOFTWARE 
DEVELOPMENT  SYSTEMS 


DIGITAL  INTERFACE  TEST  SET  (DITS) 


•  GENERAL  PURPOSE  MINI/MICROCOMPUTER 

-  EMULATE  MIL-STD-1553B 

•  LRUs 

•  BUS  CONTROLLER 

•  BUS  MONITOR 

-  PORTABLE  PIECE  OF  TEST  EQUIPMENT 

-  CAN  BE  USED  AS  AN  INTEGRAL  PROCESSOR  IN 
AN  AVIONICS  CONFIGURATION 

SUMMARY 


FACILITY  CAN  BE  USED  TO: 

•  DESIGN  AND  DEVELOP  AVIONICS  SYSTEMS 

•  HARDWARE  AND  SOFTWARE  TEST 

•  SUBSYSTEM  AND  SYSTEM  INTEGRATION 

•  REDUCE  DEVELOPMENT  COSTS 
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DISCUSSION 


W.VogI,  Ge 

What  is  the  effort  required  to  introduce  changes  to  the  simulated  scenario  in  the  understanding  that  the  scenario  is 
one  of  the  key  elements  in  the  simulator  tasks? 

Author’s  Reply 

Changes  to  the  scenario  can  easily  be  made  during  the  runtime  portion  of  the  simulation  by  simply  pausing  the 
simulation,  altering  the  desired  parameters  and  then  continuing  the  simulation.  If  halting  the  simulation  is 
undesirable  the  user  makes  the  changes  via  a  second  copy  of  the  simulation  that  has  been  built  with  shared  Images. 
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SOFTWARE  TESTING  OF  SAFETY  CRITICAL  SYSTEMS 


J.  Stocker 

MESSERSCHMIjTT -BOELKOW-BLOHM-GMBH 
Aircraft  Division 

D-8000  Muenchen  80,  Postfach  801160 


SUMMARY 

Safety  critical  systems  must  be  thoroughly  tested.  Powerful  test 
facilities  and  test  concepts  are  very  important.  -The^aper  outlines 
methods  used  for  testing  the  software  of  the  Tornado  Autopilot 
^  and  Flight  Director  System  (AFDS) .  An  overview  of  existing  test 
systems  is  given,  followed  by  a  detailed  presentation  of  a  new  test 
faci 1 ity  AFDS  Cross  Software  Test  System  (AFDS-CSTS). 

The  CSTS  is  an  automated  tool.  The  AFDS  is  stimulated  by  a 
test  computer  with  wel^xjiefined  test  data,  generated  via  a  test 
language.  A  software  model  running  on  this  test  computer  is  stimu¬ 
lated  with  the  same  test  data.  This  software  model  is  programmed 
according  to  the  dual  programming  method  based  on  the  AFDS  software 
specification.  The  test  computer  compares* cycle  by  cycle>the  out¬ 
puts  of  the  AFDS  with  the  software  model  outputs.  All  deviations 
from  expected  results  are  recorded  for  subsequent  analysis. 

The  experience  gained  by  installing  and  using  this  tool  is  reported. 
The  quality  and  the  test  effectiveness  of  this  test  method  are  dis¬ 
cussed.  <50trnSport ant  point  is  the  cost  of  testing'  futurr  software 
modifications. 


/ 

T  ^  i  s  — > 


1.  INTRODUCTION 

The  role  of  digital  computers  for  system  control  and  the  operation  of  modern  weapon  sys¬ 
tems  is  expanding.  Such  computer  applications  are  often  safety  involved,  partially 
highly  safety  critical.  So  it  is  very  important  to  achieve  a  high  degree  of  reliability 
in  the  hardware  and  software. 

This  paper  describes  the  software  test  methods  applied  to  the  Autopilot  and  Flight 
Director  System  (AFDS)  of  the  Tornado.  Especially  a  new  automated  test  tool  is  present¬ 
ed:  The  AFDS  Cross  Software  Test  System  (AFDS  CSTS). 


2.  DESCIPT10N  OF  THE  SYSTEM  TO  BE  TESTED 
2.1  Global  function 

The  Tornado  AFDS  is  a  digital  integrated  subsystem  that  allows  the  automatic  control  of 
the  aircraft  in  all  three  flight  axes.  It  also  provides  the  pilot  with  informations  on 
instruments  and  displays.  So  the  pilot  can  manually  guide  the  aircraft  using  the  flight 
director  mode  or  can  monitor  the  automatic  flight.  The  automatic  modes  include: 

-  Attitude/Heading  hold  mode 

-  Barometric  altitude  hold  mode 

•  Mach  hold  mode 

-  Terrain  following  mode 

-  Radar  height  hold  mode 

-  Bank  angle  hold  mode 

-  Heading  acquic'tion  mode 

•  Track  acquisition  mode 

-  Autothrottle  mode 

The  system  (see  Fig.1)  receives  its  inputs  from  sensors,  other  subsystems  and  pilot  in¬ 
puts  on  the  control  stick  or  on  the  control  panel.  The  autopilot  receives  inputs  from: 

-  Inertial  navigation  system  (INS) 

-  Secondary  attitude  and  heading  reference  system  (SAHRS) 

-  Air  data  computer  (AOC) 

•  Main  computer  (NC) 

-  Radar  altimeter  (RA) 

-  Terrain  following  computer  (TFC) 

•  Command  and  stability  augmentation  system  (CSAS) 

•  Approach  aids 

-  Throttle  lever 

-  '  lot's  control  unit 

-  Pilot's  control  stick 


The  outputs  of  the  AFDS  are  transmitted  to  the: 

-  Command  and  stability  augmentation  system  (CSAS) 

-  Head  up  display  (HUD) 

-  Attitude  and  direction  indicator  (ADI) 

-  Autothrottle  actuator 

-  Pilot's  control  unit,  engage  indicator,  central  warning  panel,  maintanence  panel 


Fig.1.:  Block  schematic  of  Tornado  Flight  Control  System 

The  AFDS  outputs  'pitch  rate  demand'  and  'roll  rate  demand'  are  transmitted  to  the  CSAS 
and  indirectly  control  the  rudder,  spoilers  and  tailerons  of  the  Tornado.  Especially  in 
low  altitude  flight  faults  on  these  output  signals  could  be  very  critical.  Therefore 
the  AFDS  must  be  considered  as  a  very  safety  critical  system  and  all  possible  measures 
have  to  be  taken  to  avoid  hardware  and  software  failures. 


2.2  Protection  against  AFDS  hardware  failures 

The  AFDS  is  a  duplex  redundant  system.  Two  almost  Identical  computers,  which  are  self- 
monitored  execute  an  identical  program.  They  only  differ  in  some  interfaces.  The  com¬ 
mand  signals  at  various  stages  of  the  computation  are  crossfed  between  the  two  computers 
and  checked.  If  the  signal  difference  exceeds  a  certain  tolerance  treshold,  a  hardware 
failure  in  one  computer  is  assumed,  a  pull  up  is  generated  and  the  automatic  mode  is 
switched  off.  By  this  method  the  AFDS  recognizes  hardware  failures  and  protects  the 
system  from  their  dangerous  effects. 

Software  errors  however  would  appear  In  both  computers  and  would  have  the  same  effects 
In  both  computers.  Software  errors  can  not  be  detected  by  hardware  redundancy.  There¬ 
fore  other  measures  have  to  be  taken  to  avoid  software  errors  and  to  validate  the 
software. 


3.  MEASURES  TO  ACHIEVE  HIGHLY  RELIABLE  SOFTWARE 
3.1  Characterisation  of  the  AFDS  software 

The  AFDS  software  is  a  program  of  medium  size.  The  number  of  Instructions  Is  less  than 
ten  thousand.  It  has  been  programmed  in  assembler  language  and  loaded  Into  PROMs.  It 
is  structured  essentially  Into  three  main  parts: 

-  The  Mode  and  Failure  Logic  selects  the  operating  modes  according  to  the  pilot  re¬ 
quests,  priority  matrices  and  sensor  validity.  It  determines  the  system  reaction  in 
the  case  of  hardware  failures.  It  consists  essentially  of  logical  AND-  and  0R- 
connections  and  delays  of  logical  states. 

-  The  Control  Laws  compute  the  commands  in  the  three  flight  axes  In  dependency  of  the 
selected  modes  and  the  sensor  and  pilot  Inputs.  The  main  part  are  arithmetic  compu¬ 
tations,  filters,  limiters.  Integrators. 

•  Built-In  test  equipment  (BITE)  routines 

The  Mode  and  Failure  Logic,  the  Control  Laws  and  parts  of  the  BITE  routines  are  cycli¬ 
cally  executed  In  an  endless  loop.  The  AFDS  hardware  Interfaces  transmit  the  Inputs  and 
outputs  of  the  program  '  'from  certain  data  memory  locations  In  parallel  to  the  program 
execution.  Additional.  to  the  program  outputs  sent  to  the  CSAS  and  the  different 
displays,  signals  at  various  stages  of  the  computation  can  be  monitored  on  the  flight 
test  channel.  There  Is  a  variety  of  input/output  signals:  digital  parallel,  digital 
serial,  discrete,  analog,  synchros.  In  total  there  are  more  than  40  discrete,  20 
dlgltal/analog  input  signals  and  more  than  150  discrete,  45  digital/analog  output  sig¬ 
nals,  relevant  to  the  AFOS  software. 


3.2  Classification  of  applied  measures 

For  safety  critical  systems  like  the  AFOS  naturally  a  lot  of  measures  are  taken  to 
achieve  highly  reliable  software  and  to  assure  software  confidence.  There  are  many  dif¬ 
ferent  activities  during  the  different  stages  of  the  AFOS  software  development.  The 
most  Important  are  outlined  below  and  classified  according  to  [33 . 
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a.  First  of  ail  everything  is  used  to  make  the  software  as  error  free  as  possible. 
Therefore  constructive  fault  avoidance  measures  have  been  applied  beginning  at  the 
earliest  phase  of  the  software  development  process  down  to  the  system  integration 
phase.  For  example  special  emphasis  has  been  put  on  systematic  requirements 
analysis,  careful  specification,  top  down  design,  structured  programming.  Generally 
good  software  engineering  methods  are  very  important. 

b.  Then  ail  kinds  of  dynamic  tests  -  dynamic  analytical  fault  avoidance  measures  -  are 
applied  on  all  levels  to  detect  possible  existing  errors.  Extensive  dynamic  tests 
are  not  only  applied  to  the  final  integrated  software  package,  but  also  to  every 
software  module  during  the  software  development. 

c.  Also  static  tests  -  static  analytical  fault  avoidance  measures  -  have  been  applied. 
Code  inspections  of  the  AFDS  source  code  have  been  partially  made.  The  AFDS  source 
program  listing  has  been  visually  analyzed  and  checked  with  the  intent  of  detecting 
programming  errors. 

d.  Furthermore  fault  tolerant  measures  have  been  taken.  That  means  the  AFDS  software 
has  been  constructed  in  that  way  that  certain  possible  software  errors  cannot  advance 
to  the  program  outputs,  at  least  not  to  their  full  size.  For  example  software  lim¬ 
iters  are  built  into  the  different  places  of  the  AFDS  software  keeping  the  effects  of 
possible  previous  software  errors  to  a  minimum.  Besides  the  most  critical  outputs 
are  monitored  by  hardware  authority  limiters  that  restrict  the  output  signals  to  a 
certain  range. 

e.  Last  but  not  least  procedural  fault  tolerant  measures  are  taken.  For  example  the 
flight  tests  and  tfie  flight  clearance  of  the  critical  automated  flight  modes  are 
started  at  safe  altitudes.  Software  errors  would  not  result  with  a  high  degree  of 
probability  in  a  crash,  because  there  would  be  enough  time  to  switch  off  the  automat¬ 
ic  AFDS  mode,  to  control  the  aircraft  manually  and  to  recover  the  aircraft  from  a 
critical  flight  manoeuvre. 

This  paper  concentrates  on  the  dynamic  software  test  methods  of  point  b.,  which  are  ap¬ 
plied  by  MBB  to  the  AFDS  as  delivered  subsystem.  The  tests  during  the  development  phase 
-  module  tests,  module  integration  tests  -  are  the  task  of  the  AFDS  supplier  and  are  not 
described  here. 

The  AFDS  -  hardware  and  software  -  has  been  developed  by  Marconi  Avionics.  The  customer 
set  up  the  system  requirements  and  the  system  specification.  The  developer  developed 
the  system  applying  all  possible  quality  assurance  measures.  After  the  AFDS  computers 
have  been  loaded  with  the  software  they  are  shipped  to  the  customer.  Then  a  lot  of  sub¬ 
system  tests  and  integration  tests  on  different  test  facilities  were  executed  by  MBB. 
The  system  responsiblity  is  on  MBB  and  therefore  MBB  has  the  greatest  interest  to  test 
the  AFDS  system  thoroughly. 


3.3.  Dynamic  software  test  methods  applied  and  test  facilities  available  at  MBB 
3.3.1  Acceptance  tests 

These  tests  are  executed  on  a  test  bench.  The  inputs  to  the  AFDS  are  supplied  with 
static  voltages  and  bit  patterns.  Some  outputs  are  measured  and  compared  with  prede¬ 
fined  expected  results.  These  tests  should  check  above  ail  the  correct  functionning  of 
each  single  computer  (material  defect,  production  defects).  Therefore  every  AFDS  com¬ 
puter  has  to  be  subjected  to  this  test,  indeed  the  AFDS  software  is  indirectly  tested 
by  this  method,  but  the  number  of  the  test  points  is  too  small  to  check  the  AFDS 
software  thoroughly. 


3.3.2  Closed  loop  rig  tests 

A  rig  system  provides  the  capability  of  performing  avionic  system  integration  by  real¬ 
time  simulation.  All  avionic  sensors,  LRU's  and  other  equipment  are  installed  as  real 
equipment  or  they  are  simulated  •  so  as  the  aircraft  dynamics  -  by  a  simulation  comput¬ 
er.  They  are  connected  as  on  the  aircraft.  The  various  control  panels,  the  control 
stick  etc.  can  be  used  as  in  normal  aircraft  operation.  The  behaviour  of  this  test  fa¬ 
cility  is  equivalent  to  real  flight  situations.  A  data  handling  computer  monitors  the 
inputs  and  outputs  of  the  avionic  equipment.  Further  details  can  be  found  in  other  pub¬ 
lications  [6] . 

The  objective  of  closed  loop  rig  tests  is  to  evaluate  the  performance  and 
hardware/software  integrity  of  a  system/subsystem  under  normal  and  abnormal  flight  si¬ 
tuations.  The  flight  tests  are  supported  by  simulating  abnormal  inflight  occurances  or 
answering  test  pilot  questions.  More  in  detail: 

-  The  performance  analysis  tests  in  the  case  of  the  AFDS  investigate  the  design  of  the 
AFDS  software,  the  Tayout  of  the  control  laws  and  of  the  mode  and  failure  logic. 
They  check  if  the  overall  system  requirements  are  met. 

-  The  system  behaviour  has  also  to  be  checked  under  abnorma 1  situations.  Especially 


the  ability  of  the  AFDS  is  investigated  to  detect  failures  of  lanes,  interfaces  and 
components  and  to  react  in  a  reasonable  manner. 

-  Finally  software  confidence  tests  are  »  ecu ted  on  the  rig.  That  means  test  pro- 
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of  the  control  laws  and  the  mode  and  failure  logic. 


3.3.3  Flight  tests 

Flight  tests  are  executed  when  the  rig  tests  have  demonstrated  that  the  system  works 
with  a  satisfactory  degree  of  confidence.  The  flight  clearance  is  restricted  at  the  be¬ 
ginning  to  a  limited  envelope  until  sufficient  confidence  is  gained  from  flight  experi¬ 
ence.  The  flight  tests  are  a  final  proof  of  the  system  performance. 


3.4  Why  build  a  new  automated  test  tool 

As  a  new  link  in  this  chain  of  tests  and  test  facilities  described  above  the  Cross 
Software  Test  System  (CSTS)  has  been  developed.  The  objective  was  to  evaluate  the 
correct  implementation  of  the  AFDS  software  and  to  perform  software  confidence  tests. 
The  AFDS  software  should  be  tested  as  a  hardware/software  integrated  subsystem  to  recog¬ 
nize  possible  interface  or  hardware  problems. 

Software  confidence  tests  are  very  time  consuming  and  expensive: 

-  Because  of  the  multitude  of  the  program  inputs  and  their  combination  possibilities  a 
lot  of  tests  has  to  be  executed  to  reach  a  satisfactory  test  coverage  and  complete¬ 
ness. 

-  All  tests  have  to  be  repeated  if  the  AFDS  software  is  modified,  even  if  the  modifica¬ 
tions  affect  only  some  modules.  Side  effects  of  the  local  modifications  could  influ¬ 
ence  other  modules. 

-  Because  of  the  costs  involved  a  rig  test  should  only  be  used  for  integration  testing 
and  not  for  finding  errors  in  a  line  replacable  unit. 

-  Testing  is  very  time  consuming  and  difficult  in  spite  of  automated  stimulating  and 
recording  by  a  test  computer.  In  the  ideal  case  all  test  results  must  be  compared 
with  predefined  expected  outputs.  If  this  principle  is  not  applied,  there  is  a 
chance  that  a  plausible  but  erroneous  result  will  be  interpreted  as  a  correct  one. 
The  cause  is  based  on  human  psychology  and  the  phenomenon  that  "the  eye  is  seeing 
what  it  wants  to  see"  Q4] .  The  application  of  this  principle  to  the  AFDS  is  res¬ 
tricted  by  the  complexity  of  the  computations  and  the  extent  of  the  tests.  Often  ex¬ 
pected  results  can  be  g’ven  only  with  great  tolerances  or  they  are  derived  from  the 
results  of  a  neighbouring  te«tpoint  definition. 

Therefore  we  wanted  to  develop  a  new  test  tool,  that  executes  the  AFDS  software  confi¬ 
dence  tests  as  far  as  possible  automatically.  Thus  the  number  of  the  tests  can  be  in¬ 
creased  and  the  test  coverage  and  quality  can  be  improved  without  additional  expense. 

In  the  following  pages  this  new  automated  test  tool  is  described:  The  AFDS  Cross 
Software  Test  System  (AFDS  CSTS). 


4.  DESCRIPTION  OF  CSTS 
4.1  Principle  of  CSTS 

The  AFDS  computers  loaded  with  the  software  programs  are  coupled  with  a  test  computer,  a 
PDP  11/70  (see  Fig. 2).  All  input/output  signals  of  the  AFDS  are  stimulated/recorded  by 
hardware  interfaces  (digital/analog  converters,  analog/digital  converters,  digital  in¬ 
terfaces,  synchro  signal  converters). 

A  model  of  the  AFDS  software  is  executed  on  a  PDP  11/70.  It  has  been  developed  accord¬ 
ing  to  the  dual  programming  method:  The  base  of  the  software  model  is  the  specification 
of  the  AFDS  software.  But  apart  from  that  it  is  totally  dissimilar  to  the  AFDS 
software: 

-  Both  programs  run  on  different  machines.  The  computer  architecture  of  the  PDP  and 
the  AFDS  are  totally  different.  The  PDP  uses  floating  point  arithmetic,  the  AFDS 
fixed  point  arithmetic. 

-  The  software  model  on  the  PDP  and  the  AFDS  program  have  been  programed  in  different 
languages:  The  software  modei  in  the  high  order  language  C,  the  AFDS  program  in  as¬ 
sembler. 

-  The  design  and  the  development  process  of  the  AFDS  software  and  the  software  model 
were  different. 

-  The  programming  teams  were  independent 

Because  of  this  dissimilarity  the  probability  is  very  low  that  errors  in  the  AFDS 
software  and  in  the  software  model  are  in  identical  places  and  have  the  same  erroneous 
effects. 

Furthermore,  because  of  the  characteristic  of  floating  point  arithmetic  and  of  high  ord¬ 
er  languages  some  error  sources  are  omitted  in  the  software  model.  In  floating  point 


arithmetic  you  have  normally  not  to  care 
about  overflow,  scaling  or  accuracy  prob¬ 
lems.  Programs  written  in  an  high  order 
language  tend  to  have  fewer  errors,  be¬ 
cause  they  are  shorter  and  clearer. 

Finally  because  of  the  software  model  pro¬ 
gramming  method  not  only  implementation 
errors  could  be  detected,  but  also  errors 
in  the  specification.  The  programmers 
were  at  the  beginning  of  the  CSTS  develop¬ 
ment  new  to  the  AFOS  software  specifica¬ 
tion.  They  tried  to  understand  the  con¬ 
tents  of  the  specifications  completely  and 
checked  once  again  all  formulas  and 
descriptions  critically.  Ambiguities  and 
unprecise  formulations  have  been  clarified 
in  close  contact  with  the  AFDS  system  en¬ 
gineers.  (Not  recognized  ambiguities  of 
the  specification  are  detected  during  the 
CSTS  test  at  the  latest).  Then  the  pro¬ 
grammed  software  model  has  been  given  to 
AFDS  system  engineers  to  make  a  code  in¬ 
spection. 


A  test  driver  stimulates  the  AFDS  computers  and  the  software  model  with  identical  in¬ 
puts.  It  receives  all  outputs  of  the  AFOS  computers  and  compares  them  with  the  outputs 
of  the  software  model.  If  it  detects  a  discrepancy  between  a  software  model  output  and 
an  AFDS  output,  it  recognizes  this  as  an  error,  breaks  off  the  test  and  protocols  the 
deviating  results. 

The  error  situation  is  manually  analyzed  to  determine  the  source  and  the  location  of  the 
error.  The  error  can  be  either  in  the  AFDS  or  in  the  software  model.  The  erroneous 
program  is  corrected  and  the  tests  are  repeated.  The  CSTS  tests  are  finished,  if  all 
tests  are  executed  without  any  discrepancies. 

These  tests  are  all  executed  in  real-time.  The  CSTS  automates  all  parts  of  a  test  as 
far  as  possible.  The  test  execution  and  the  checking  of  the  test  results  is  totally  au¬ 
tomatic.  The  stimulation  data  sequences  don't  have  to  be  defined  explicitly,  but  only 
the  formulas  for  their  generation.  The  analysis  of  a  detected  discrepancy  is  supported 
by  the  additional  listing  of  all  available  intermediate  results. 


4.2  CSTS  hardware  structure 

The  core  of  the  CSTS  hardware  is  a  POP  11/70  computer,  surrounded  by  a  set  of  standard 
devices:  3  terminals  for  program  development  and  test  control,  a  type  writer  as  operator 
console,  a  line  printer  for  generating  test  reports,  a  magtape  for  system  backup,  and 
two  10  MB  removable  disks.  A  lot  of  special  interfaces  couple  the  test  computer  to  the 
AFDS  inputs  and  outputs:  digital  inputs/outputs ,  analog  inputs/outputs,  serial  digital 
inputs/outputs  and  synchro  outputs.  A1 1  AFDS  inputs  and  outputs  are  connected  to  the 
CSTS  test  computer.  Even  the  power  lines  to  the  AFDS  can  be  interrupted  by  computer 
controled  relays.  Thus  power  failure  situations  could  be  simulated  and  analyzed.  The 
crossfeed  signals  between  both  AFDS  computers  are  controled  too.  Additionally  an 
8-channel-recorder  is  installed  to  recorc  selected  AFDS  or  software  model  inputs  or  out¬ 
puts.  Also  a  special  interface  is  installed  that  enables  the  synchronous  execution  of 
the  AFDS  and  the  POP  program. 


4.3  CSTS  software 
4.3.1  Design  principles 

The  most  important  design  principles  were  to  use  a  test  language,  to  execute  the  total 
test  in  real-time  and  to  construct  the  system  hardware  and  software  so  universal,  that 
it  could  easily  be  adapted  to  new  requirements. 

Each  test  is  completely  described  by  commands  that  are  written  on  disk  files.  Therefore 
all  tests  are  reproducable  and  exactly  protocoled.  The  test  commands  are  easy  to  under¬ 
stand.  They  control  all  test  actions:  They  define  the  generation  rules  of  the  stimula¬ 
tion  data,  they  adjust  parameters  needed  during  the  comparison  of  software  model  and 
AFDS  outputs  (tolerances,  masks),  they  select  parameters  and  time  slices  that  should  be 
protocoled. 

The  real-time  ability  has  been  made  possible  by: 

-  Generating  of  the  stimulation  data  at  test  execution  time  by  interpretation  of  test 
commands 

-  Running  of  the  software  model  at  test  execution  time  in  parallel  to  the  AFDS 

-  Comparing  the  outputs  of  AFDS  and  software  model  during  the  test  execution,  only  de¬ 
viating  results  are  stored. 


Fig. 2:  Principle  of  CSTS 


Therefore  no  disk  or  magtapes  are  needed  to  store  the  huge  amount  of  data.  The  size  of 
a  magtape  for  example  would  only  suffice  to  store  half  an  hour  of  stimulation  data, 
model  outputs  and  AFDS  outputs.  Because  of  this  real-time  design  no  magtapes  or  disks 

have  to  be  mounted  or  dismounted.  The  duration  of  the  tests  is  not  restricted  by  space 

or  time  limits.  In  addition  this  design  concept  delivers  new  possibilities  to  generate 
stimulation  data.  The  AFDS-  or  software  model  outputs  of  the  previous  program  cycle  can 
be  used  to  generate  the  stimulation  data  of  the  next  program  cycle.  For  example  if  the 
AFDS  disengages,  then  a  reengagement  can  be  forced  setting  the  autopilot  engage  request 
signal. 

Because  the  software  is  table  driven,  it  is  easy  to  modify  and  expand.  The  hardware  was 
also  designed  to  be  easily  modified  and  expanded.  Because  of  this  flexible  design  the 

FSW  can  fe  ly  it  p‘  to  AtC*  modifies*  ion*  <jp  to  few  Im.  application!. 


Fig. 3:  Software  Structure  of  CSTS 


4.3.2  Stimulation  features 

A  great  deal  of  the  test  commands  are  used  to  generate  stimulation  data.  The  main 
features  of  these  commands  are  listed: 

-  all  stimulation  and  output  signals  are  named  symbolically 

-  values  in  assignements  are  given  either  in  units  or  in  volts 

-  there  is  a  command  defining  incremental  or  decremental  changes  of  a  stimulation 
parameter 

-  there  are  sinus  or  saw  tooth  functions  to  vary  parameters  continuously  with  freely 
adjustable  frequencies  and  amplitudes 

-  the  pressing  of  switches  on  the  pilot  control  unit  or  the  control  stick  can  be  simu¬ 
lated  whereby  the  duration  of  pressing  is  adjustable 

-  lists  of  signals  can  be  stimulated  in  all  possible  permutation  sequences 

-  in  arithmetic  and  logical  expressions  all  standard  operators  can  be  used 

-  some  signals  can  be  automatically  computed  to  inhibit  sensor  monitor  trips  in  the 
AFDS 

-  if  -  then  -  else  statements 

-  loops 

-  parallel  execution  of  computation  blocks 


4.3.3  Features  of  output  comparison 

Normally  all  outputs  of  both  AFDS  computers  are  compared  with  the  corresponding  software 
model  outputs.  The  outputs  are  compared  after  eacn  AFDS  program  cycle.  By  special  test 


commands  the  following  things  are  adjustable: 

-  Tolerances  define  the  allowed  deviations  between  digital/analog  AFDS  and  software 
model  outputs.  The  tolerances  can  be  defined  in  percent  of  the  maximum  possible 
value  or  In  volts.  Deviations  of  a  few  percents  have  to  be  allowed  because  of  the 
noise  on  the  analog  input  and  output  signals. 

-  Single  outputs  can  be  excluded  from  the  comparison.  This  was  very  useful  during  the 
integration  phase  of  the  CSTS. 

-  The  number  of  tolerable  successive  errors,  before  an  error  is  reported,  is  adjustable 

A  software  error  is  assumed  and  the  test  is  broken  off,  if  the  difference  of  any  com¬ 
pared  output  pair  is  greater  then  the  allowed  deviation  and  it  is  present  longer  than 
the  allowed  number  of  successive  errors.  In  addition  to  these  standard  checks  special 
plausibility  checks  are  freely  definable.  They  are  realized  by  if-then-statements. 
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4.3.4  Test  analysis  utilities 

Besides  the  CSTS  supports  the  analysis  of  the  errors  with  some  utilities: 

-  An  error  trace  listing  is  automatically  generated,  if  a  discrepancy  is  detected.  It 
lists  all  AFDS  and  software  model  inputs  and  outputs  -  inclusive  of  all  available  in¬ 
termediate  results  -  of  a  program  cycle.  The  number  of  the  protocoled  cycles  before 
and  after  en  error  is  adjustable.  The  observed  discrepancies  are  marked.  At  the  top 
of  this  listing  the  test  commands  defining  the  test  are  printed  and  the  test  command 
is  marked  where  the  error  was  detected. 

-  The  error  trace  listing  can  be  explicitly  generated  on  each  location  of  the  test 

-  8  input/output  signals  can  be  recorded  in  real-time  on  an  8-channel-recorder.  The 

signals  and  their  scaling  are  selected  by  test  commands. 


5.  EXPERIENCES  GAINED  DURING  CSTS  INTEGRATION 

During  the  integration  phase  of  the  CSTS  we  had  to  solve  some  problems  that  are  typical 
of  such  test  tools.  We  wanted  to  allow  only  small  deviations  between  software  model  and 
AFDS  outputs  so  that  the  CSTS  tests  could  be  very  sensitive.  As  preconditions  for  that 
we  had  to  eliminate  all  secondary  output  falsifications  resulting  from  the  coupling  CSTS 
to  AFDS: 

-  The  synchronisation  between  the  test  computer  and  the  AFDS  had  to  be  exact.  The  in¬ 
terface  delay  times  had  to  be  taken  into  consideration. 

-  Problems  originated  from  different  algorithms  and  different  precisions  of  arithmetic 
calculations.  They  were  mostly  located  on  testpoints  outside  of  the  normal  flight 
envelope.  Some  modifications  of  the  software  model  were  made  because  of  this. 

-  Noise  on  the  analog  lines  could  not  be  avoided.  Therefore  we  set  the  allowed  toler¬ 
ances  above  these  tresholds. 

Although  the  use  of  the  analog  signals  caused  some  problems,  the  inclusion  of  the 
hardware  increases  the  quality  of  the  CSTS  tests.  Not  only  coding  errors,  errors  of  the 
assembler,  the  compiler  and  the  run  time  system  can  be  found,  but  also  faults  of  the  in¬ 
terfaces  and  of  the  processor. 

Absolute  orecondition  for  the  analysis  of  the  detected  discrepancies  was  the  availabili¬ 
ty  of  the  complete  system  documentation  and  of  results  on  the  flight  test  channels  and 
the  crossfeed  links.  Otherwise  it  would  have  been  almost  impossible  to  determine  the 
reasons  for  deviations.  Therefore  it  is  necessary  to  think  of  the  test  abilities  al¬ 
ready  during  a  subsystem  design. 
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6.  EVALUATION  OF  CSTS 

The  CSTS  fulfills  all  classic  requirements  of  testing:  All  tests  are  completely  docu¬ 
mented.  They  can  be  exactly  reproduced.  The  expected  results  are  predefined.  The 
tests  are  fully  automatically  executed.  Thereby  the  number  of  tests  can  be  significant¬ 
ly  increased.  The  tests  themselves  are  very  rigorous,  because  a  1 1  outputs  are  tested 
after  every  program  cycle  against  very  precise  nominal  outputs.  The  effectiveness  of 
the  CSTS  has  been  shown  by  the  detection  of  some  minor,  non  critical  errors.  Detailed 
investigations  about  dual  programming  demonstrate  the  quality  of  such  test  methods  [5], 
r.7]. 

It  was  not  intended  to  use  the  CSTS  to  replace  the  other  tests  or  test  facilities.  A 
combination  of  different  tests  that  complement  each  other  provide  greater  assurance  of 
correctness.  The  CSTS  has  been  developed  to  test  especially  the  correct  implementation 
-  software  and  hardware  -  of  a  safety  critical  subsystem  and  to  perform  software  confi¬ 
dence  tests  as  far  as  possible  automatically.  But  also  ambiguous  formulations  in  the 
specification  are  detected. 

The  costs  of  the  CSTS  are  in  essential  nonrecurring.  Repeated  applications  in  the  case 
of  AFDS  modifications  require  scarcely  additional  expense.  Only  the  software  model  has 
to  be  modified  and  the  test  procedures  have  to  be  extended  by  parts  that  test  the  new 
modifications.  The  other  routines  remain  unchanged.  The  test  execution  itself  is  au¬ 
tomatic  as  described  above. 
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With  small  enlargements  of  the  hardware  the  CSTS  could  be  used  for  other  tasks,  for  ex¬ 
ample  for  acceptance  tests.  Because  of  the  universal  design  the  CSTS  could  be  recon¬ 
structed  with  low  costs  for  other  systems  to  be  tested. 

In  conclusion  it  can  be  stated  that  the  CSTS  lowers  in  the  long  run  the  costs  of  testing 
safety  critical  subsystems  increasing  simultaneously  the  number  and  quality  of  tests. 
Certainly  it  could  be  applied  to  other  subsystems  of  modern  weapon  systems. 
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DISCUSSION 


K.F.Boecking,  Ge 

(1)  Can  you  test  with  this  system  that  e.g.  an  additional  A  =  B  +  C  will  work  well  under  all  allowable  numbers  for 
B  and  C? 

(2)  In  addition,  can  you  make  sure  with  the  testing  system  that  there  will  be  no  condition  under  which  the  AFDS 
runs  into  a  dead  end  or  hang  up  itself? 

Author's  Reply 

(1)  Because  the  tests  run  totally  automatically  the  number  of  (B,  C)-combinations  can  be  increased  at  will  without 
any  additional  costs. 

(2)  The  architecture  of  the  AFDS  processor  inhibits  a  hang  up  of  the  AFDS  already.  In  addition  the  AFDS  has 
been  tested  under  a  very  high  number  of  extreme  conditions.  Therefore  the  probability  is  very  low  that  such 
problems  remain  undetected. 


W.S. Bennett,  US 

(1)  Have  you  done  any  dynamic  frequency  response  testing  between  your  simulated  software  and  machine  soft¬ 
ware? 

(2)  If  you  have,  what  evaluation  have  you  had  over  a  large  frequency  range? 

Author’s  Reply 

All  tests  have  been  executed  dynamically.  The  input  parameters  have  been  varied  with  different  frequencies.  But 
because  the  simulated  software  and  the  machine  software  run  synchronously  we  have  got  a  one-to-one  correlation. 


N.J.B.Young,  UK 

My  question  is  in  three  parts: 

(1)  Have  you  measured  the  effectiveness  of  your  techniques,  e.g.  by  using  bug  seeding? 

(2)  How  often  do  apparent  faults  shown  up  by  your  system  turn  out  not  to  be  faults  at  all  but  due  to 
i.e.  differences  between  fixed  and  floating  point  arithmetic? 

(3)  When  a  fault  is  signalled,  how  much  work  does  it  take  to  locate  its  source? 

Author’s  Reply 

(1 )  We  have  just  finished  the  development  and  execution  of  tests.  Detailed  investigations  about  the  test  effective¬ 
ness  will  be  made  in  the  near  future. 

(2)  Discrepancies  due  to  e.g.  differences  between  fixed  point  and  floating  point  arithmetic  were  mostly  located  on 
testpoints  outside  the  normal  flight  envelope.  Through  slight  careful  modifications  in  the  software  model  such 
effects  could  be  avoided  in  the  following  tests. 

(3)  Because  the  history  of  all  inputs,  outputs  and  available  intermediate  results  of  AFDS  and  software  model  has 
been  printed  in  the  case  of  a  fault,  the  source  of  the  fault  could  be  very  easily  located,  mostly  in  less  than  one 
or  two  hours. 
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^Continuing  growth  in  the  number  of  high-integrity  sof twa re -based  systems  is  causing  a 
corresponding  growth  in  the  problems  of  software  testing  (or,  more  generally,  software 
validation).  In  recent  years  there  has  been  growing  interest  in  a  variety  of  validation 
techniques  but  the  problem  of  how  to  apply  these  in  a  practically  useful,  cost-efficient, 
automated  form  has  not  been  resolved.  This  paper  classifies  some  available  techniques 
against  a  concept  of  automatability  and  identifies  directions  in  which  they  can  be 
improved  for  usefulness  rather  than  for  academic  interest.  One  promising  technique  is 
'symbolic  execution'  and  the  results  of  a  detailed  study  are  presented.  A  reduction  in 
routine  testing  costs  by  ,a  factor  of  two  to  three,  as  well  as  other  benefits,  can  be 
achieved  in  many  cases. 


Introduction 


Software  for  aerospace  applications  is  algorithmic  in  nature  :  that  is,  it  performs 
functions  or  solves  problems  by  performing  a  finite  sequence  of  operations,  in  this  case 
a  sequence  of  machine  code  operations  in  a  computer.  The  concept  of  an  algorithm  is  not 
new.  It  goes  back  at  least  to  ancient  Greece,  and  algorithms  for  arithmetic  problems 
were  well  known  in  the  Middle  Ages.  More  recently  the  growth  in  the  use  of  computers 
has  led  to  an  explosion  in  the  number  of  algorithms,  correct  and  incorrect,  in  use. 

The  number  of  software  based  systems  for  high  integrity  applications,  for  example 
aerospace  applications,  is  also  expanding  rapidly  and  is  outstripping  our  ability  to 
validate  such  software.  Three  general  approaches  have  been  taken  to  resolving  this 
problem: 

i)  To  reduce  the  need  for  software  validation  by  better  design  techniques,  the  use  of 
High  Order  Languages  and  problem  statement  languages,  the  application  of  Quality 
Procedures  during  software  design  and  modification,  etc. 

ii)  To  improve  the  effectiveness  of  traditional  testing  methods  by  standardisation, 
application  of  Quality  Procedures,  extension  of  the  domain  of  testing  methods  (from 
the  testing  of  routines  through  to  the  testing  of  entire  software  systems),  snd  by 
attempting  to  measure  the  effectiveness  of  these  methods.  Within  this  approach  wt 
may  include  dual  coding,  hardware-in-the-loop  testing,  error  logging  and  bug 
seed ing . 

iii)  To  introduce  new  methods  for  validating  software.  This  includes  what  have  become 
known  as  'proving'  techniques,  such  as  the  use  of  assertions,  to  give  proofs  of 
software  correctness  in  the  same  sense  as  mathematical  theorems  can  be  proved. 

'Proving'  techniques  are  often  distinguished  from  'testing'  techniques  in  that  the 
latter  are  noted  to  be  sble  to  demonstrate  only  the  presence  of  errors,  not  their 
absence.  This  distinction  will  not  be  emphasised  in  this  paper  and  indeed  is  at 
present  of  little  practical  interest  -  programs  for  which  correctness  'proofs'  have 
been  published  have  been  shown  to  have  flaws  (Reference  1). 

This  paper  is  concerned  with  the  third  approach  and  with  conventional  testing  from  the 
viewpoint  of  co st-ef f ec t ivene s 9  and  automatability.  It  should  however  be  noted  that 
certain  developments  in  design  techniques,  especially  the  introduction  of  new  High  Order 
Languages  rich  in  language  facilities,  may  actually  produce  software  which  is  harder  to 
validate.  An  extreme  example  is  given  in  Reference  2. 

The  'Perfect  Automatic  Software  Testing  Device' 

Let  us  first  formulate  a  concept  of  what  would,  in  a  perfect  world,  be  a  'perfect 
automatic  software  testing  device'.  Then  we  can  strip  away  some  of  its  characteristics 
in  order  to  formulate  an  objective,  no  longer  perfect  but  still  useful,  against  which  we 
can  assess  our  current  techniques,  and  which  we  may  be  able  to  achieve  in  practice. 

i)  The  perfect  device  would  be  a  black  box,  into  which  we  would  feed  our  software  and 
out  of  which  would  come  a  test  report  and  a  statement  of  correctness  or  incorrectness. 

ii)  The  perfect  device  would  act  essentially  instantaneously  and  would  require  no 
operator  intervention  or  action. 

iii)  The  perfect  device  would  accept  software  in  sny  form  in  which  it  already  exists  and 
would  require  no  additional  input. 

iv)  The  output  would  be  comprehensive  but  brief  and  in  a  generally  acceptable  form.  If 

an  unmodified  and  a  modified  version  of  the  software  were  both  input  the  difference  1 

in  their  effect  would  be  immediately  apparent  from  the  output. 

v)  The  input  software  could  be  of  any  type,  for  any  function,  and  of  any  length.  f 

vi)  The  device  would  detect  errors  of  any  type,  including  both  specification  and 

implementation  errors,  and  any  data-dependent  errors  which  might  occur  in  just  a  l 

small  part  of  the  data  domain.  | 
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vii)  The  device  would  not  ‘only  detect  errors  in  the  software  presented  to  it  but  would 
also  highlight  problems  in  integrating  this  with  other  software. 


An  Achievable  Objective? 


Now  let  us  reduce  the  characteristics  of  the  perfect  device  to  try  to  formulate  an 
achievable  objective  which  is  appropriate  to  our  requirements: 


i)  The  objective  is  a  simulation  package,  into  which  we  would  feed  our  software  and 
out  of  which  would  come  a  test  report  in  the  best  possible  form. 

ii)  It  would  produce  its  output  speedily  and  require  little  operator  involvement. 

ii)  It  would  accept  software  in  machine  code  (runnable)  form  and  a  minimum  of  test 
specification  information. 

iv)  The  output  would  be  comprehensive  but  brief  and  in  a  form  suitable  for  Quality 
auditing.  The  output  would  readily  show  the  results  of  any  software  modification. 

v)  The  input  software  could  be  usefully  long.  Modern  design  techniques  suggest  a 
preferred  maximum  software  module  size  of  fifty  statements  and  this  must  be  the 
minimum  achievable.  We  may  restrict  the  software  to  be  tested  to  that  suitable  for 
high  integrity  defence  applications  (for  example),  so  that  if  we  wish  the  software 
will  have  to  be  well  structured  and  not  include  any  inherently  unsafe  constructs. 
(For  example,  WHILE  loops  have  no  predetermined  limit  of  execution  times  and  may  be 
considered  inherently  unsafe;  and  are  often  forbidden  in  high  integrity  software. 
FOR  loops,  by  comparison,  are  not  necessarily  inherently  unsafe).  We  may  restrict 
the  software  source  language  to  assembly  code  or  a  Defence  standard  High  Order 
Language  such  as  CORAL  66  in  the  UK  (Reference  3)  initially  for  a  Defence  standard 
processor.  Given  these  restrictions  it  is  an  objective  that  a  high  proportion  of 
software  modules  can  be  tested. 

vi)  vii)  The  achieveability  of  these  characteristics  of  the  perfect  device  will  be  left 

for  consideration  until  the  end  of  this  paper. 


In  summary,  the  objective  is  a  form  of  software  validation,  widely  but  not  universally 
applicable,  for  use  on  Defence  projects,  automatable,  with  good  error  coverage  and 
convenient  output  format. 


Automatability  Concept 


It  should  be  emphasised  that  the  concept  of  automatability  of  testing  applies  to  all 
aspects  of  testing,  including  the  preparation  of  software  for  automatic  testing  and  the 
examination  of  output.  There  is  little  benefit  in  an  'automatic'  testing  process  which 
requires  for  example  extensive  and  costly  preparation  of  a  test  specification  or  gives 
an  output  which  is  less  comprehensible  than  the  original  code.  Automating  the  teating 
of  software  involves  reducing  all  aspects  of  the  work  of  the  human  tester  while 
increasing  the  understanding  of  the  operation  of  the  software  provided  by  the  test 
output.  Since  the  quantity  of  test  preparation  and  results  examination  work  is  directly 
related  to  the  required  degree  of  understanding  of  the  software  module  by  the  human 
tester,  we  can  define  (in  subjective  units): 


A  -  Degree  of  automatability  achieved 


Insight  gained  from  test 
Work  by  tester  required 


We  shall  find  that,  contrary  to  expectation,  very  high  values  of  A  are  achievable 
(techniques  achieving  this  will  be  termed  'highly  A-automatable ' )  .  We  now  assess  some 
software  validation  techniques  against  this  concept  of  automatability. 


Conventional  Numerical  Testint 


A  software  module  may  be  represented  (fig.  1)  as  a  process  by  which  inputs  are  converted 
to  outputs.  Conventional  numerical  testing  involves  running  the  module  with  predefined 
input  data  and  comparing  the  outputs  with  predefined  supposedly  correct  results.  In 
practice  the  modules  may  be  run  on  target  hardware  using  an  in-circuit  emulator  or  in  a 
cross-simulator  on  another  machine  (to  take  two  examples)  but  this  does  not  affect  the 
principle  of  the  test.  The  test  may  regard  the  module  as  a  'black-box'  and  only  be 
concerned  with  inputs  and  outputs;  or  as  an  internally  examinable  'white-box',  and 
additionally  inspect  intermediate  results,  paths  followed,  etc. 


The  writing  of  a  test  specification  is  a  task  of  significant  size,  and  the  maintenance 
and  rewriting  of  test  specifications  throughout  the  modification  life  of  a  module 
represents  a  considerable  part  of  life  cycle  costs.  Further,  modifying  a  test 
specification  to  correspond  to  a  modified  module  is  a  highly  error-prone  process. 

It  is  very  difficult  to  relate  testing  efrort  to  achievement  -  to  know  'how  much  is 
enough' . 


It  is  often  preferred  that  there  be  independence  between  those  implementing,  those 
specifying  and  those  performing  tests  on  the  module.  But  when  the  test  is  performed  it 
is  highly  probable  that  there  will  be  a  discrepancy  between  the  supposedly  correct  and 
actual  results.  Resolving  such  a  discrepancy  involves  examining  not  only  the  module 
implementation,  but  also  possibly  the  test  specification  and  even  the  module  specification. 
This  compromises  the  independence  of  the  testing  process.  It  is  also  likely  that  those 
working  in  the  same  environment,  to  the  same  procedures,  will  make  similar  assumptions. 
Their  'independence'  is  therefore  to  a  considerable  extent  illusory. 
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Further,  with  these  methods  of  testing  there  remains  the  possibility  of  an  undiscovered 
data-dependent  error.  The  test  specification  and  test  results  are  usually  large 
documents  and  therefore  difficult  to  examine  in  detail  and  expensive  to  archive. 

The  degree  of  A-automatibility  achieved  is  therefore  low. 


Dual  Coding 


In  dual  coding  the  module  specification  is  implemented  twice,  once  for  the  target 
machine  and  a  second  time,  perhaps  in  a  different  language  on  a  different  machine.  Dual 
coding  itself  requires  more  work  but  reduces  the  need  for  test  specifications  as  outputs 
from  the  two  versions  can  be  compared.  However  the  main  criticisms  of  conventional 
numerical  testing  also  apply  to  dual  coding. 

Spectral  Observation  and  Hardware-in-the-Loop  Testing 

In  spectral  observation  very  large  quantities  of  input  data  are  generated  (eg.  by  some 
pseudo-random  scheme)  but  only  statistical  information  is  collected  about  the  outputs. 
The  output  spectrum  (fig.  2)  is  then  examined  for  apparent  anomalies.  This  technique 
may  give  insight  on  data-dependent  errors  but  only  detects  very  particular  types  of 
anomaly.  Ha rdware-in-the- loop  testing  with  performance  measuring  and  anomaly  recording 
is  usually  preferred;  but  as  with  dual  coding  the  detection  of  a  discrepancy  in  itself 
gives  little  information  on  where  or  why  it  has  occurred. 


Code  Reading 

Of  the  conventional  techniques  assessed  in  this  paper,  code  reading  by  a  second  party 
gives  the  greatest  improvement  of  insight  into  the  operation  of  a  module,  though  it 
requires  considerable  work  to  achieve  this.  We  can  regard  the  other  techniques  assessed 
below  as  being  an  automated  or  assisted  version  of  code  reading. 

Control-Flow  and  Data-Flow  Analysis 

(A  good  account  of  this  and  other  techniques  assessed  below  is  given  in  Reference  4). 
The  basis  of  control  flow  analysis  is  that  each  program  should  have: 

i)  A  single,  initial  START  (or  ENTRY)  statement  with  no  predecessors. 

ii)  One  or  more  final  HALT  (or  EXIT)  statements  with  no  successors. 

iii)  No  jumps  to  non-existent  labels. 

iv)  No  labels  to  which  no  jumps  exist. 

v)  No  statements  which  'cannot'  be  reached  from  the  START  statement. 

vi)  No  statements  from  which  a  HALT  statement  'cannot'  be  reached. 

('cannot'  usually  meaning  the  non-existence  of  any  path.  But  even  if  a  path  existed,  it 
might  not  be  feasible,  i.e.  the  path  condition  might  be  logically  false). 

As  is  well  known,  this  form  of  analysis  can  be  performed  automatically  by  certain 
compilers  and  other  utilities.  Such  an  analysis  is  only  a  very  partial  test  but  it 
requires  no  user  effort  and  can  highlight  apparent  anomalies. 

Data  flow  analysis  checks  that: 

a)  Variables  are  not  used  before  being  given  a  value  (or  more  usually  before  being 
able  to  be  given  a  value  along  at  least  one  feasible  path). 

b)  Variables  once  given  a  value  can  be  used  (in  particular  before  being  given  a  new 
value) . 


These  checks  highlight  anomalies  which  may  indicate  errors  of  understanding  (eg.  data 
scope  errors),  misspellings,  confusion  of  names  and  omission  of  statements. 

Again,  this  analysis  may  be  able  to  be  performed  automatically  by  a  compiler  without 
user  effort. 

These  analyses  are  highly  A-automatable ,  providing  user  insight  post-test  without 
requiring  any  pre-test  insight.  They  are,  however,  of  extremely  restricted  usefulness 
without  further  extension. 

Flow-Chart  Reduction 

Dij stra-structured  programs  can  be  'reduced'  to  a  single  statement  by  iteratively 
reducing  recognised  structures  (sequences,  selections,  iterations)  in  the  code  to  single 
statements.  Other  programs  may  not  be  reducible  in  this  way  (fig.  3).  Automated 
reduction  can  be  achieved  (Reference  4)  though  with  considerable  algorithmic  difficulty 
for  larger  programs  (Reference  5)  and  the  process  can  provide  considerable  insight  into 
the  software  structure  that  has  actually  been  implemented,  without  user  effort.  Again 
this  method  is  highly  A-automatable. 


Acyclic  Segment  Analysis 


This  technique  can  be  applied  to  program  segments  which  contain  no  indeterminate  loops 
or  in  which  all  such  loops  can  be  'reduced'  to  a  single  higher  order  statement.  All  the 
possible  paths  through  the  segment  (which  contains  conditional  expressions)  are 
identified  and  are  listed  separately  with  the  logical  condition  under  which  the  path 
will  be  executed. 

A  proportion  of  the  peths  will  not  be  executable  because  their  logical  conditions  are 
always  false  and  these  need  not  be  tested.  In  a  study  by  Knuth  (summarised  in  Reference 
4)  only  a  few  percent  of  ell  paths  were  executable,  and  the  clarification  of  the  logical 
conditions  for  the  remainder  may  suggest  simplifications  and  highlight  errors  or 
neglected  possibilities.  Studies  on  high-integrity  engine  control  software  at  DOWTY 
ELECTRONICS  suggest  that  between  one  and  two  thirds  of  paths  in  typical  routines  may  not 
be  executable. 

This  method  is  mainly  a  guide  to  how  to  conduct  further  testing,  and  is  therefore  not 
comprehensive,  but  has  high  A-automat ibil ity . 


Assertion  Techniques 

Assertion  techniques  (sometimes  just  called  formal  program  proving  techniques)  require 
the  user  to  make  precise  statements  (assertions)  of  what  is  true  about  the  program 
variables  at  different  points  in  the  program.  The  assertions  are 
transformations  corresponding  one-to-one  with  the  code  statements 

through  the  program.  It  can  then  be  checked  that  the  transformed  assertion  from  one 
point  is  precisely  the  essertion  at  a  second  point. 


then  subjected  to 
as  they  'travel' 


Assertion  techniques  are  of  major  academic  interest  since  they  are  similar  in  form  to 
some  mathematical  theorem  proving  techniques  and  they  are  the  only  general  software 
proving  techniques  yet  known  capable  of  demonstrating  the  correct  termination  of 
indeterminate  iterative  (eg.  WHILE )  loops.  But  it  is  not  at  all  certain  that  they  are 
useful  in  practice.  Firstly,  WHILE  loops  can  often  be  avoided  in  high  integrity 
software  by  using  non-iterative  or  determinate  iterative  (FOR  loop)  methods,  and  in  many 
cases  occur  only  in  a  small  number  of  modules.  Secondly,  assertions  are  extremely 
difficult  to  define  since  they  should  be  exactly  as  strong  as  is  required  to  contain  all 
the  required  characteristics  of  a  program.  Thirdly,  assertion  proofs  are  usually  proofs 
at  a  High  Order  Language  level  and  therefore  may  not  be  valid  at  machine  code  level. 
Other  objections  are  given  in  Reference  6. 

Assertion  techniques  at  present  have  very  poor  A-automatabil ity  due  to  their  requirement 
for  major  user  involvement.  To  resolve  this  it  would  be  necessary  to  devise  techniques 
for  automatic  generation  of  assertions  from  program  code. 

Symbolic  Execution 

Symbolic  execution  of  a  module  is  an  advanced  simulation  technique  in  which  input 
variables  are  assigned  symbolic,  not  numeric,  values.  The  results  of  such  simulations 
are  algebraic  equivalents  to  the  program  paths  followed.  These  results  can  be  compared 
directly  with  the  module  specification,  not  the  test  specification  for  essentially  no 
test  specification  is  required  (no  values  need  be  specified  for  symbolic  variables). 

Symbolic  execution  was  identified  by  DOWTY  ELECTRONICS  as  a  technique  which  was 
potentially  both  comprehensive  and  highly  A-automateble  provided  that  certain  problems 
in  Implementing  the  technique  could  be  overcome.  A  major  research  and  development 
programme  was  therefore  initiated  to  achieve  both  high  automat abil ity ,  low  cost-of-use, 
and  improved  testing  coverage  compared  with  conventional  numerical  testing.  The 
remelnder  of  this  paper  gives  an  account  of  what  has  been  achieved. 

(Note  that  this  method  is  quite  distinct  from  what  is  sometimes  called  'symbolic 
debugging'  i.e.  conventional  numerical  testing  in  which  variebles  are  accessible  not  by 
location  but  by  their  High  Order  Language  names). 

Basic  Idee 

The  basic  idea  of  symbolic  execution  can  be  illustrated  by  a  simple  example.  Consider 
the  program  fragment  in  some  arbitrary  High  Order  Languege: 

X  -  Y  +  Z  ; 

Suppose  we  wish  to  test  this  by  ccnventional  numerical  methods.  We  would  assign  Y  end  Z 
numerical  values,  sey  2  and  3.  We  then  execute  the  program  fragment  and  achieve  the 
numerical  result  S  (we  hope).  We  then  repeat  the  test  for  other  values  until  we  are 
satisfied  of  correctness. 


In  symbolic  execution  we  assign  to  Y  and  Z  not  numerical  values  but  symbolic  values,  ' y ' 
and  'a'  say.  The  machine  code  form  of  the  program  fragment  is  then  symbolically 
executed  and  the  result  is  e  symbolic  string  'y  +■  *'  (assigned  to  X)  which  is  readily 
identifiable  as  algebraically  equivalent  to  the  original  High  Order  Language  version. 
(Since  we  symbolically  executed  the  machine  code  version  of  this  program  we  have 
effectively  de-compiled  that  version  back  into  the  High  Order  Language).  Since  'y'  and 
's'  could  represent  any  numerical  value  we  have  teated  the  fragment  for  all  numerical 
valuea. 


. . 


A  software  nodule  will  typically  contain  conditional  expressions  involving  symbolic 
values  and  there  will  therefore  be  many  paths  through  the  module,  each  with  its  own 
logical  path  condition  on  the  input  variables  (compare  Acyclic  Segment  Analysis,  above). 
In  general,  then,  a  symbolic  execution  output  will  consist  of  a  set  of  results,  one  for 
each  path,  consisting  of  a  path  condition  and  symbolic  strings  assigned  to  locations, 
typically  in  the  form: 

Path  condition  1  :  a  ”  ' -  -  - ' 

b  -  ' - -• 


Path  condition  2  :  a  =  *-  -  -• 
etc . 

The  main  difficulty  in  applying  this  technique  is  that  the  number  of  paths  may  be  very 
large.  Since  every  path  must  be  symbolically  executed  the  volume  of  results  could 
become  unmanageably  large.  It  is  possible,  though  not  necessarily  desirable,  to 
identify  and  eliminate  infeasible  paths  during  symbolic  execution,  but  the  general  data 
reduction  problem  is  not  fully  resolved  by  this. 


Comparison  of  Ac 


Symbolic  execution  is  not  a  new  idea  and  it  is  useful  to  compare  the  DOWTY  ELECTRONICS 
approach  to  this  technique  with  published  studies. 


Howden,  in  an  empirical  comparative  study  of  software  validation  techniques  (Reference 
7)  found  symbolic  exacution  to  be  a  relatively  effective  testing  technique,  but  regarded 
it  as  an  expensive  technique  to  use.  (Not  in  agreement  with  the  results  of  the  DOWTY 
ELECTRONICS  study). 


Several  studies  (referred  to  in  Reference  4)  have  been  made  of  the  possibility  of 
automating  symbolic  execution  of  programs  at  the  High  Order  Language  level  (not  machine 
code  level).  In  this  approach  the  symbolic  values  are  assigned  to  High  Order  Language 
data  types  which  could,  for  example,  be  multi-word  floating  point.  Their  conclusions 
are  in  accord  with  Howden.  (1  agree  that  this  is  a  useful  technique  for  testing  at  a 
later  stage,  after  symbolic  execution  at  the  machine  code  level,  effectively  decompiling 
the  machine  code,  has  been  performed). 


Carter  et  al  (Reference  8)  applied  symbolic  execution  to  microprograms,  observing  that 
all  data  types  could  be  broken  down  into  bit  arrays  (and  therefore  arrays  of  symbolic 
values,  one  for  each  bit,  would  be  required).  In  this  study  data  reduction  was 
performed  whenever  a  new  expression  was  created.  The  authors  were  able  to  study 
microprograms  of  considerable  complexity. 


The  DOWTY  ELECTRONICS  approach  exploited  modern  developments  in  software  design  and  the 
characteristics  of  the  type  of  software  (high  integrity  software,  for  engine  control  for 
example)  of  major  concern  to  the  company  (Reference  2).  Effectively  only  one  data  type, 
the  machine  word  length  (16-bit)  variable,  was  considered  for  the  majority  of  the  study. 
(Though  this  cculd  represent  either  integer  or  fixed  point  real  variables.  This  is  also 
in  accordance  with  the  general  approach  embodied  in  the  UK  Defence  standard  language, 
CORAL  66,  Reference  3).  No  attempt  was  made  to  perform  data  reduction  until  after  the 
symbolic  execution  process  had  been  completed  and  all  paths,  feasible  and  infeasible, 
were  executed.  The  testing  of  infeasible  paths  is  important  since  a  software  modification 
may  have  the  unintended  effect  of  making  an  infeasible  path  feasible,  and  this  should  be 
immediately  apparent  on  comparison  of  the  two  sets  of  symbolic  execution  results.  This 
approach  exploits  the  modern  quality  requirement  that  modules  should  be  of  small  size 
will  a  manageable  number  of  paths. 


Only  input  variables  were  made  symbolic  (refer  fig.  1).  Local  variables  and  constants 
were  handled  numerically  where  possible  but  were  allowed  to  form  parts  of  strings,  for 
example  'y  +  7'.  This  hybrid  approach  had  considerable  advantages  of  ease  of  use  and 
cost  reduction. 


At  an  early  stage  in  the  DOWTY  ELECTRONICS  programme  it  was  realised  that  symbolic 
execution  could  not  only  provide  effective  decompilation  of  machine  code  programs  but 
could  also  be  used  to  trace  the  flow  of  data  into  (sometimes  undesired)  areas.  This 
aspect  will  be  described  first. 


Data  Tracint 


In  real-time  recursive  software  the  tracing  of  data  items  on  successive  iterations  is  a 
serioue  problem.  For  example,  it  should  be  checked  that  initialisation  and  exception 
handling  are  correctly  performed  and  that  initialisation/exception  data  disappear  from 
the  syeteti  after  an  appropriate  number  of  recursion  cycles.  It  should  also  be  checked 
that  no  extraneous  side-effects  such  as  the  corruption  of  other  data  areas  can  occur. 


Fig.  4  shows  as  a  simple  example  a  routine  for  updating  a  three-deep  stack  of  previous 
data  valuea.  On  each  recursion  this  stack  is  updated  with  the  latest  value.  Fig.  5 
snows  the  result  of  a  simple  error  which  causee  the  stack  to  be  only  partially  updated. 
This  error  would  normally  be  found  by  conventional  testing.  But  consider  fig.  6.  In 
this  case  the  module  specification  has  been  mieunderstood  and  the  data  stack  grows  with 
potentially  disastroua  results,  possibly  after  a  considerable  elapse  of  real  time. 
Whether  this  would  be  detected  or  not  depends  purely  on  the  test  specification  -  and  a 
test  specification  which  did  not  detect  this  error  would  be  unlikely  to  be  recognised  as 
inadequate  by  Quality  Proceduree. 


A  generally  unresolved  problem  in  reel-time  software  at  least  in  practice  is  to  prove 
that  asynchronous  tasks  cannot  corrupt  each  others  data  areas.  Consider  for  example  a 
low  priority  task  which  is  interrupted  and  suspended;  one  or  more  other  tasks  are  run 
and  the  low  priority  task  is  then  restored.  We  wish  to  ensure  that  the  operation  of  the 
suspended  task  has  not  been  corrupted.  This  requirement  can  be  written  in  general  terms 
as : 

I-1  H  I  M  -  M  VHeH.VM 

where  M  is  the  machine  state  before  interrupt  (more  exactly,  that  'part'  of  the  machine 
state  relevant  to  the  interrupted  task),  1  is  the  process  of  interruption  and  suspension, 
and  M  is  the  set  of  all  possible  transformations  associated  with  the  higher  priority 
task  or  tesks.  By  exploiting  the  characteristics  of  symbolic  execution  (tracing  of  data 
by  symbolic  value  and  execution  of  all  possible  paths)  the  user  can  identify  the  data 
interactions  between  tasks,  if  any.  The  details  are  left  to  the  reader,  who  is  advised 
that  he  will  discover  multifarious  problems  but  also  multifarious  solutions  using  the 
power  of  the  symbolic  execution  concept. 

Algebraic  Results  (and  Effective  Decompilation) 

As  well  as  providing  data  tracing  facilities,  symbolic  execution  provides  formulae,  each 
equivalent  algebraically  to  a  program  path. 

The  output  from  a  simple  error-counting  routine  of  thirteen  instructions  is  shown  in 
tree  diagram  form  in  fig.  7.  On  either  of  two  error  conditions  the  routine  increments 
en  error  counter,  limiting  at  three.  If  there  is  no  error  the  routine  decrements  the 
counter,  limiting  at  zero.  In  pseudocode: 

if  (bit  1  of  C  -  1  OR  bit  1  of  B  -  0) 

then  (200)  :  ■  Minimum  of  (3,  (200)  +  1) 
else  (200)  :  ■  Maximum  of  (0,  (200)  -  1  ) 
endif 


where  (200)  is  the  contents  of  location  200,  the  error  counter.  (200)  was  given  the 
symbolic  value  a  end  the  symbolic  execution  results  are  given  in  fig.  7. 

These  results  ere  now  examined  es  follows: 

i)  The  union  (logicel  OR)  of  all  the  peth  conditions  is  logical  TRUE.  This  is  merely 
e  check  on  the  testing  process  itself,  to  determine  that  all  paths  have  been 
symbolically  executed.  In  this  case  ell  paths  ere  feasible.  Now  e'ech  peth  in  turn 
is  compered  with  the  pseudocode  definition  of  the  routine. 

ii)  Peth  1 

(200)  :  -  Min  (3,  e+ 1 )  -  3  es  expected  since  e  >  2 

iii)  Peth  2 

(200)  :  -  Min  (3,  e+1)  -  e+1  es  expected  since  e  ' 2 

iv)  Peth  3 

Conditions  e  i  0  is  not  sufficient  if  'e'  cen  teke  ell  possible  values  (both 
negative  end  positive).  When  'e'  is  negative  e-I  will  be  negative  end  Max  (0,  e-1) 
should  be  0,  but  the  result  indicates  e-1  will  be  chosen.  Either  extra  information 
on  the  input  range  of  'e'  should  be  included  in  the  routine  definition  or  the 
routine  should  be  re-coded  defensively. 

v)  Peth  4 

(200)  :  •  Max  (0,  e-1)  -  0  es  expected  since  e«0 

vi)  Peth  5 

(200)  j  •  Min  (3,  e+1)  ■  3  es  expected  since  e^2 

vii)  Peth  6 

(200)  :  ■  Min  (3,  e+1)  •  e+1  en  expected  since  e t  2 

viii) The  results  should  also  be  examined  to  determine  the  effects  of  in  en  arithmetic  or 
comparison  operation  (see  also  Reference  2). 

Cost  Comparison 

In  the  study  the  symbolic  execution  test  was  performed  semi-eutomet icel ly  using  e 
numerical  simulator  with  operator  intervention  to  record  symbolic  intermediate  results 
according  to  e  formalised  (end  therefore  automatable)  schedule,  end  was  compared  with 
conventional  numerical  testing.  The  results  ere  shown  in  Teble  1.  Note  that  even  in 
semi-automatic  form  symbolic  execution  comperes  well  with  numerical  testing;  end  in  e 
projected  fully  automated  form  it  comperes  extremely  well.  The  physical  size  of  the 
results  was  also  much  reduced.  The  tester  was  not  previously  femilier  with  symbolic 
execution  and  required  training  of  approximately  three  hours. 

Capabilities 

As  part  of  the  DOWTY  ELECTRONICS  study,  symbolic  execution  was  applied  to  typical 
software  taken  from  existing  engine  control  applications.  The  study  found  that: 

i)  The  comparisons  in  Table  1  generally  remained  valid. 

ii)  Symbolic  execution  could  be  applied  to  larger  software  modules  of  up  to  fifty 
instructions  with  ease;  end  up  to  seventy-five  instructions  typical  maximum  with 
difficulty  at  the  present  stage  of  development  of  the  technique.  (The  size  problem 
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only  arises  due  Co  additionel  conditional  stetements  increasing  the  number  of 
peths.  The  same  problem  exists  with  numerical  testing). 

iii)  The  visibility  of  the  test  results  was  better  than  for  numerical  testing  (mainly 
due  to  reduction  in  their  size). 

iv)  70  to  80Z  of  software  modules  can  be  tested  eiher  wholly  or  with  parts  separately 
modulerised  (elso  required  in  these  cases  with  numerical  testing). 

v)  No  fundemental  problems  were  encountered.  For  effective  use  the  technique  requires 

the  use  of  speciel  notation  which  was  developed  during  the  study.  A  major 

achievement  was  to  solve  the  problem  of  recording  condition  register  results.  The 
notetion  was  designed  for  equal  convenience  for  eutomated  computer  handling  and  for 
results  presentation. 

vi)  Tlie  approach  of  performing  the  symbolic  execution  first  without  data  reduction 
(e.g.  elimination  of  infeasible  paths)  was  confirmed  as  best. 

vii)  It  was  found  that  the  technique  hed  several  unpredicted  benefits  arising  from  the 

extra  insight  it  provided  into  the  operation  of  the  implemented  software  module 

(i.e.  the  method  is  highly  A-automateble) .  Examples  from  particular  cases  are: 

*  Recognition  that  an  apperently  single  function  module  could  be  divided  into 

two  separate  modules  each  with  fewer  inputs  and  outputs  (relevant  to  design 

for  testability). 

*  Highlighting  of  date  range  or  initialisation  requirements  (as  found  for  the 

simple  error  counting  routine,  above). 

*  Highlighting  of  specification  errors.  In  some  cases  this  resulted  from  the 

high  visibility  of  the  test  results  when  the  comperison  with  the  module 

specification  was  made,  but  in  other  cases  the  tester  stated  from  a  subjective 
judgement  of  the  test  results  (without  referring  to  the  specification)  that  a 

module  was  'obviously  wrong'.  This  aspect  of  the  psychology  of  testing  is  not 

yet  understood. 

Conclusions 

The  particuler  advantages  of  symbolic  execution  are: 

i)  The  enforced  testing  of  every  peth  through  the  program  module  under  test. 

ii)  The  detection  of  dete-dependent  errors. 

iii)  The  highlighting  of  init ialiset ion  and  data  range  requirements  and  some  specification 
errors . 

iv)  The  effective  elimination  of  test  specifications  which  are  very  time  consuming  to 
prepare  and  difficult  to  updete  without  error. 

v)  The  'objectivity'  of  the  method  in  the  sense  that  the  number  of  tests  is  not  et  the 
discretion  of  the  tester.  This  mey  be  compered  with  the  'how  much  is  enough' 
problem  in  numericel  testing. 

vi)  The  testing  at  mechine  code  level  of  code  originally  written  in  essembly  code  or  e 
High  Order  Language.  (This  provides  protection  against  compiler  errors). 

vii)  The  visibility  of  results  (especially  when  investigating  the  effects  of  modifications), 
and  in  particular  their  relatively  small  volume. 

viii) The  ability  to  trace  data  items  and  investigate  cross-corruption  in  a  multi-tasking 
real-time  system,  providing  a  test  facility  for  integrated  software  systems. 

ix)  High  A-automatebility . 

x)  Hide,  though  not  universal,  applicability. 

xi)  Cost  effectiveness.  Even  the  semi-automatic  method  compares  well  with  conventional 

numerical  testing.  The  study  indicates  that  full  autometion  will  provide  a 

reduction  in  software  testing  costs  by  a  factor  of  two  to  three  for  modules  of 
typical  aize. 

These  characteristics  can  be  compared  with  thoae  of  the  'perfect  automatic  software 

testing  device’  and  ths  objective  for  achievement  described  early  in  this  paper. 

Symbolic  execution  has  been  shown  to  compare  very  well  in  its  area  of  application. 

DOWTY  ELECTRONICS  are  currently  preparing  the  eutomation  (the  ' prod uc t ionising ' )  of  the 

techniques  already  developed  into  a  symbolic  execution  testing  package  for  Defence 

applications . 
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Figure  1  Data-flow  description  af  software  module  as  process 


Figure  2 


Spectral  observation  -  range  of  outputs 


TABLE  1  COMPARISON  OF  SYMBOLIC  EXECUTION  AND  NUMERICAL  TESTING 
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DISCUSSION 


A.O.Ward,  UK 

Is  there  a  limit  to  the  size  of  module  that  the  method  can  be  applied  to? 

Author’s  Reply 

Our  objective  was  that  the  output  from  a  symbolic  execution  test  of  a  module  should  be  comprehensive  but  brief 
and  provide  insight  to  the  tester;  in  particular  we  wanted  to  improve  on  what  could  be  achieved  using  conventional 
numerical  testing.  Using  symbolic  execution  in  “effective  decompilation”  mode,  the  complexity  of  the  test  output 
grows  with  the  size  of  the  module  being  tested,  since  additional  conditional  statements  increase  the  number  of  paths 
to  be  tested.  (The  same  problem  exists  with  conventional  numerical  testing).  Tests  on  typical  modules  have  shown 
that  symbolic  execution  ceases  to  be  useful  beyond  a  module  size  of  75  instructions  at  the  present  stage  of  develop¬ 
ment  of  the  technique;  typical  modules  of  50  instructions  can  be  handled  with  ease.  This  is  sufficient  for  Defence 
quality  software  modules.  The  majority  of  our  work  has  been  with  software  written  in  assembly  code  but  initial 
investigations  suggest  that  the  figures  for  High  Order  Languages  are  similar,  even  though  one  HOL  line  equates  to 
several  assembly  code  instructions  (but  may  not  introduce  additional  paths).  It  is  possible  that  future  development 
of  the  symbolic  execution  technique  may  extend  the  maximum  module  size,  but  I  think  it  is  more  important  now 
to  concentrate  on  incorporating  automated  module  testing  into  schemes  for  automating  the  testing  and  validation  of 
sub-systems  and  complete  software  systems:  -  but  these  schemes  are  still  under  development. 
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SUMMARY 


In  the  successful  development  of  major  aircraft  ^projects  such  as  Jaguar,  Tornado  IDS  and  Tornado 
F  Mk  2,  (the  WarErn  Division  of  British  Aerospace  PLC\has  accumulated  a  great  deal  of  experience  in 


avionic  systems  development  testing. 


■  /li  A 


The  pre-flight  ground  test  philosophy';  adopted? is  based  on  the  construction  of  an  avionics  systems 
development  rig.  Although  the  rig  concept  remains  central  to  our  philosophy,  rig  testing  techniques 
have  <had  to/  chang&jas  -t hep  avionics  systems  have  increased  in  complexity  and  influence  throughout  the 
aircraft. 

The  techniques  presently  employed  are  made  possible  due  to  two  main  factors;  ^namely 

-Ti le  adoption  of  an  integrated  approach  towards  the  use  of  and  interaction  between  the 
avionics  rig  and  other  development  facilities.  Oca-  .4 

^  -  Si  ff- 

'  (4>  —-star increase  in  the  use  of  computing  for  the  data  acquisition  and  simulation  tasks. 

This  has  resulted  in  a  shift  in  emphasis  from  static  to  dynamic  system  testing  and  the  avionics 
development  rig  for  the  Tornado  F  Mk  2  is  capable  of  simulating  flight. 

Thus,  it  is  possible  to  exercise  the  avionics  systems  throughout  the  aircraft  mission  envelope  on 
the  rig  before  flight  testing  begins.  This  capability  represents  a  considerable  cost  saving/  in  4hec5L 
development  of -th«F; avionics  systemsj>^since  reductions  in  the  aircraft  flight  test  progrannief  have  been 
achieved  and  ttl£>  /light  testing  time  is  being  used  more  effectively. 

4L _ 

The  dynamic  testing  technique  and  its  advantages  form  the  basis  of  this  paper  which  describes  the 
Torndao  F  Mk  2  avionics  rig  facility  and  its  operation. 


1 .  INTRODUCTION 

The  development  of  an  avionic  system  for  the  modern  military  aircraft  is  a  lengthy  process 
including  many  hours  of  system  testing,  both  on  the  ground  and  in  the  air.  The  overall  objective  is 
of  course  to  prove  that  the  system  meets  the  specifications  and  functions  as  advertised.  In  order  to 
reach  this  goal,  from  the  initial  design  phase  through  to  the  delivery  to  the  customer,  BAe  Warton 
utilise  numerous  development  facilities  including  : 

Mathematical  Modelling 

Flight  Simulators 

Avionics  Development  Rigs 

The  Flight  Test  Programme 

Each  of  the  above  plays  a  dominant  role  at  some  stage  in  the  development  process,  however,  there 
has  always  been  interaction  between  these  areas  throughout  this  entire  period.  Whilst  this 
interaction  has  always  been  present  it  has  until  recent  years  existed  as  a  data  flow,  the  facilities 
themselves  remaining  essentially  independent. 

To  meet  the  demands  of  the  Tornado  F  Mk  2  development  programme  a  more  integrated  approach  was 
adopted  towards  the  use  of  these  facilities.  This  resulted  in  the  production  of  a  much  enhanced 

avionics  development  rig  and  significantly  increased  interaction  between  the  rig,  the  aircraft  and  the 

mathematical  modelling  process.  This  Integrated  approach  plus  nn  increase  in  the  use  of  computing  for 
the  data  acquisition  and  system  simulation  tasks  made  it  possible  to  'fly'  the  avionic  system  on  the 
ground  test  rig. 

This  capability  represents  a  significant  cost  saving  in  the  development  of  the  avionics  system 
since  flying  time  on  the  rig  is  much  less  expensive  than  actual  aircraft  flying  time. 

A  brief  account  of  the  historical  background  to  the  present  test  philosophy  is  given  and  the 

concept  of  the  avionics  development  rig  is  Introduced.  Particular  emphasis  is  then  placed  on  a 
description  of  the  Tornado  F  Mk  2  rig  and  its  operation.  The  advantages  that  have  already  been 
achieved  through  the  use  of  dynamic  testing  techniques  are  presented  and  an  indication  of  how  this 
concept  may  be  developed  for  future  use  is  Included. 
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2 .  HISTORICAL  BACKGROUND 


At  the  start  of  a  new  aircraft  project  the  avionics  rig  test  programme  incorproates  hardware 
integration,  system  development  including  hardware  and  software,  and  system  clearance  for  flight.  The 
major  part  of  this  programme  is  undoubtedly  that  which  concerns  the  development  and  proving  of  the 
operational  flight  software.  This  is  an  ongoing  task  which  continues  throughout  the  rig  life  cycle  as 
the  operational  software  is  updated,  refined  and  enhanced  to  accommodate  new  system  developments.  For 
any  new  aircraft  project,  therefore,  the  extent  and  complexity  of  the  operational  flight  software  is  a 
significant  factor  when  considering  both  development  programme  timescales  and  the  manpower 
requirements.  The  rig  test  philosophy  adopted  for  the  Tornado  F  Mk  2  project  was  based  on  previous 
experience  gained  through  successful  development  of  the  Jaguar  and  Tornado  IDS  aircraft. 

Jaguar 

The  Jaguar  aircraft  was  designed  in  the  mid  1960s  and  its  avionics  system  is  relatively  simple  by 
todays  standards.  The  system  was  built  around  a  Main  Computer  containing  8K  of  core  store  which 
housed  the  operational  flight  software.  The  system  testing  philosophy  adopted  on  the  Jaguar  avionics 
rig  involved  a  division  of  the  flight  software  into  manageable  sections  dealing  with  specific  moding 
or  mathematical  equations.  Each  section  was  then  statically  tested  on  an  individual  basis.  The 
results  of  these  tests  were  compared  to  calculated  theoretical  results  derived  from  the  software 
design  documentation.  Since  this  testing  was  essentially  static  in  nature  only  selected  points  of  the 
operational  envelope  were  covered.  To  exercise  the  software  in  a  truly  dynamic  manner  it  had  to  be 
flown  and  consequently  the  aircraft  had  to  be  used  as  a  software  development  tool.  Although  the 
ground  testing  satisfied  the  'safe-to-fly'  standard  numerous  problems  were  encountered  during  flight. 
These  problems  were  then  investigated  on  the  rig  which  often  took  considerable  time  and  effort  because 
the  in-flight  conditions  could  not  be  easily  reproduced.  Once  a  problem  was  resolved  and  corrective 
action  taken  the  aircraft  was  again  used  to  confirm  the  solution. 

Thus  the  aircraft  flight  test  programme  had  to  take  into  account  the  need  to  devote  flights  to 
system  development  before  concerning  itself  with  system  operational  assessment,  ie  the  aircraft  was 
used  to  achieve  the  'works  as  advertised'  condition  before  it  could  address  the  problem  of  : 

How  well  does  the  advertised  system  perform  its  task  ? 

Tornado  IDS 


This  aircraft  was  designed  during  the  early  1970s  and  like  the  Jaguar  its  avionics  system  was 
built  around  a  Main  Computer.  However,  the  Tornado  avionics  system  was  both  more  extensive  and 
complex  than  that  for  its  predecessor.  The  operational  flight  software  was  resident  in  the  Main 
Computer  containing  32K  of  core  store  ie  four  times  the  capacity  of  that  on  the  Jaguar.  The  software 
test  philosophy  adopted  for  the  Tornado  was  essentially  the  same  as  that  for  the  Jaguar,  hence,  the 
system  development  timescales  expanded  beyond  those  previously  experienced.  The  Tornado  aircraft  had 
to  be  used  to  assist  in  the  development  of  the  flight  software  because  this  was  the  only  way  to 
dynamically  exercise  it. 

To  assist  in  the  rig  testing  of  the  avionics  system  a  Data  Acquisition  and  Simulation  System 
(DASS)  was  developed.  The  DASS  was  required  to  monitor  and  log  the  digital  data  that  represented  the 
major  data  flow  on  the  avionics  system.  Other  data  forms  such  as  discrete,  analogue  and  syncho 
signals  were  also  accommodated.  Simulation  of  the  data  formats  and  types  was  also  possible  but 
limited  to  signal  generator  type  functions. 

As  the  development  programme  progressed  the  need  to  expand  the  data  simulation  and  the  data 
acquisition  capabilities  began  to  emerge 

Tornado  F  Mk  2 


The  advent  of  the  Air  Defence  Variant  of  the  Tornado  brought  about  a  significant  change  in  the 
avionics  systems  development  testing  philosophy.  This  was  due  to  a  number  of  reasons  but  chiefly  the 
following  : 

(1)  Unlike  the  previous  two  aircraft  which  had  predominantly  air  to  ground  roles  the  Tornado  F 
Mk  2's  prime  role  was  air-to-air.  Hence  the  emphasis  in  weapon  aiming  was  different  and 
more  complex  in  content.  In  order  to  test  the  weapon  aiming  system  the  presence  of  target 
data  was  essential. 

(2)  The  avionics  system  was  built  around  a  Main  Computer  with  a  core  store  of  64K  ie  eight 
times  that  on  Jaguar  and  twice  that  on  Tornado  IDS. 

Development  of  the  avionic  system  using  established  techniques  with  inherent  increases  in 
timescales  and  manpower  was  considered  unacceptable. 

Experience  of  the  Tornado  IDS  programs  ?  had  generated  the  idea  of  dynamic  testing  on  the  rig, 
however,  it  was  realised  that  this  could  on'y  be  achieved  by  enhanced  simulation  and  data  acquisition 
capabilities.  It  was  at  this  stage  that  the  techniques  employed  in  the  Flight  Simulator  and 
Mathematical  Modelling  areas  were  essentially  integrated  with  the  avionics  rig  facilities.  From  the 
Flight  Simulator  came  the  well  established  technique  of  driving  an  aircraft  aerodynamic  model  from 
representative  flying  controls.  From  the  Mathematical  Modelling  process  came  the  required  avionics 
system  simulations. 


» 
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This  integrated  approach  resulted  in  the  development  of  a  much  enhanced  DASS  for  the  Tornado  F  Mk 
2  avionics  development  rig  which  gave  the  rig  a  fully  dynamic  capability.  This  made  it  possible  to 
actually  fly  the  avionics  system  on  the  ground  test  rig  executing  navigation  tasks  and  operating  the 
facilities  of  the  weapon  aiming  system. 

3.  THE  AVIONIC  SYSTEM  DEVELOPMENT  RIG 


In  order  to  prove  the  avionic  system  it  has  to  be  flown  and  exercised  throughout  its  entire 
operational  envelope.  Before  this  can  be  attempted,  however,  sufficient  confidence  in  the  system 
design,  its  operational  performance  and  its  integrity  must  be  achieved  to  comply  with  a  safe-to-fly 
standard.  To  reach  this  standard  the  avionic  system  itself  is  subjected  to  a  pre-flight  ground  test 
programme  on  the  avonics  system  development  rig. 

This  rig  plus  suitable  support  equipment  provides  a  facility  on  which  the  following  objectives 
can  be  achieved  : 

(1)  Validation  of  avionic  equipment  interfaces 

(2)  Development  of  the  system  to  a  safe-to-fly  standard 

(3)  Flight  back-up 

(4)  System  familiarisation  for  aircrew  and  ground  crew 

(5)  Support  for  the  continuing  avionic  system  development  and  enhancement 

The  design  of  the  rig  is  such  that  single  equipments,  subsystems  or  the  complete  aircraft  system 
msy  be  exercised.  This  is  achieved  through  a  modular  construction  technique.  Each  module  or  bench 
houses  single  equipments  or  a  subsystem,  the  system  interfacing  wiring  and  any  special  simulation 
necessary  for  stand  alone  operation.  Apart  from  actual  cable  lengths  and  their  individual  routing  the 
interfacing  wiring  is  in  other  respects  a  reproduction  of  the  aircraft  wiring  and  conforms  to  aircraft 
standarda.  The  wiring  is  broken  via  patch  panels  to  provide  access  to  the  system  data  flow  and  to 
enable  equipment  isolation  for  stand  slone  test  purposes.  A  photograph  of  the  Tornado  F  Mk  2  rig  is 
shown  in  Figure  1. 

At  all  times  testing  is  performed  using  as  much  of  the  actusl  aircraft  equipment  as  possible, 
therefore,  the  rig  is  subjected  to  the  same  configuration  controls  as  the  aircraft.  This  control 

extends  to  the  modification  state  of  both  the  rig  wiring  and  the  aircraft  equipment  in  use,  including 

the  equipments  installation  on  and  removal  off  the  rig. 

The  rig  life  cycle  extends  for  many  years  from  the  initial  project  development  phase  testing, 
through  to  aircraft  in  service  support  and  beyond.  The  original  Jaguar  rig  is  approaching  15  years  of 
continued  use  and  is  still  actively  employed  on  weapon  system  enhancement  support  work. 

4.  THE  TORNADO  F  MK  2  RIG 


Although  the  design  of  this  rig  follows  the  same  basic  philosophy  as  that  for  the  Jaguar  and 
Tornado  IDS  counterparts  it  deviates  in  the  fact  that  it  is  capable  of  simulated  flight.  During 
flight,  navigation  tasks  cau  be  performed  and  the  full  extent  of  the  weapon  aiming  system  facilities 
can  be  exercised. 

To  achieve  this  capability  a  number  of  additional  features  from  other  development  areas  have  been 
incorproated  into  the  rig  design.  These  features,  some  of  which  originate  from  flight  simulation  and 
mathematicsl  modelling  techniques,  are  described  in  the  following  sections.  A  schematic  diagram  of 
the  rig  facility  is  shown  in  Figure  2. 

Cockpits 

To  accommodate  the  crew  for  the  rig  'aircraft',  detailed  mock-ups  of  both  pilot  and  navigators 
cockpits  are  provided.  Both  cockpits  are  designed  to  accept  the  installation  of  the  relevant  aircraft 
equipments.  The  pilots  cockpit  is  also  equipped  with  operational  aircraft  controls  such  as  stick, 
throttle  and  airbrakes.  The  electrical  outputs  from  these  controls  are  fed  as  inputs  to  the  rig  DASS. 

DASS 

The  rig  DASS  which  comprises  of  two  PDP  11/55  computers  represents  a  major  advance  over  its 
Tornado  IDS  predecessor.  Although  the  DASS  operates  as  one  machine,  functionally  it  is  split  into  two 
parts. 


Part  1  represents  the  major  interface  with  the  rig  and  the  aircraft  system  and  ia  responsible  for 
system  control,  the  data  logging  functions  and  simulation  definitions  etc. 

Part  2  houses  the  bulk  of  the  simulation  system  which  can  be  divided  into  three  major  blocks. 

(1)  The  aircraft  aerodynamic  model 

(2)  The  navigation  sensor  simulation 

(3)  The  multi  target  model 

The  operation  of  this  simulation  is  best  described  by  considering  its  performance  during  the 
execution  of  navigation  and  weapon  aiming  tasks  separately. 
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Navigation 


To  convince  the  avionics  system  that  It  is  flying,  it  needs  to  be  presented  with  representative 
navigation  sensor  data.  This  data  is  dependent  on  the  aerodynamic  state  of  the  aircraft  which  is 
realised  by  the  aircraft  aerodynamic  model.  After  initialisation  this  model  is  driven  by  variations 
to  the  lift,  engine  and  drag  characteristics  derived  from  the  stick,  throttle  and  airbrake  controls  in 
the  pilots  cockpit.  The  aerodynamic  models  output  furnishes  the  necessary  stimulus  to  drive  the 
navigation  sensor  simulation.  This  block  of  simulation  provides  the  source  of  navigation  data  for  the 
rest  of  the  aircrafts  avionics  system.  The  data  is  available  to  all  navigation  system  interfacing 
equipments  and  it  conforms  to  the  Tornado  standards  ie  it  is  identical  in  form  and  content  to  that 
which  would  be  output  by  the  real  system  for  the  same  flight  conditions.  Representative  navigation 
sensor  data  errors  can  also  be  included  for  system  accuracy  tests  as  required. 

The  avionics  system,  therefore,  can  be  flown  and  the  navigation  facilities  of  the  flight  software 
dynamically  exercised  via  the  associated  cockpit  displays  and  controls. 

Weapon  Aiming 

In  addition  to  being  able  to  perform  all  the  navigation  functions,  execution  of  the  weapon  aiming 
tasks  also  necessitates  the  presence  of  active  target  data.  This  requirement  is  met  by  the  third 
block  in  the  simulation  system  the  multi-target  model.  This  model  is  responsible  for  the  generation 
and  presentation  of  target  data  to  the  aircrafts  prime  weapon  aiming  sensor,  the  multi  mode  nose  radar 
system. 

The  targets  themselves  can  be  pre-programmed  to  fly  fixed  trajectories  or  respond  to  a  time 
history  manoeuvre  list.  The  total  number  presented  is  variable  and  if  necessary  any  one  of  the 
targets  can  be  overridden  and  controlled  separately,  from  manual  inputs,  such  that  evasive  manoeuvres 
can  be  executed.  At  all  times  the  model  is  aware  of  the  rig  aircrafts  positional  data  and  its  radar 
antenna  scan  angles.  Thus  the  model  calculates  when  to  pass  target  data  to  the  radar  on  a  strictly 
"in  beam"  decision  process.  In  real  terms  the  radar  system  itself  is  responsible  for  much  of  the 
target  data  processing  before  it  is  exported  to  the  receiving  avionic  system  equipments.  Therefore  as 
much  of  the  radar  system  as  possible  has  to  be  kept  within  the  test  loop.  This  means  that  the  target 
data  output  by  the  target  model,  which  is  in  digital  form,  has  to  be  converted  to  an  equivalent  RF 
signal  before  being  injected  into  the  radar  system. 

Radar  Target  Generator 

The  process  of  converting  the  target  data  from  the  model  to  a  radar  acceptable  RF  signal  is 
performed  by  the  Radar  Target  Generator.  This  equipment  is  provided  by  the  radar  system  manufacturer 
and  is  external  to  the  DASS  facility.  It  receives  the  digital  target  data  from  the  target  model, 
converts  it  to  an  RF  equivalent  waveform  and  injects  it  into  the  radar  system  immediately  behind  the 
radar  antenna  on  the  receiving  path. 

IFF  Target  Generator 

In  a  similar  fashion  the  target  model  also  incorporates  the  ability  to  satisfy  the  requirements 
of  the  aircrafts  IFF  interrogator  system  and  targets  can  be  pre-programmed  to  be  friendly  or  hostile 
and  will  be  detected  as  such.  As  with  the  radar  system  the  IFF  data  has  to  be  presented  at  RF  and 
therefore  an  IFF  Target  Generator  is  also  required  which  is  provided  by  the  IFF  equipment 
manufacturer. 

The  complete  target  generation  system  enables  representative  target  data  to  be  presented  to  the 
avionics  system.  Targets  are  detected,  engaged  and  the  weapon  aiming  and  missile  management  systems 
exercised  up  to  and  including  the  point  of  missile  releases.  This  is  a  very  cost  effective  means  of 
weapon  aiming  and  weapon  system  development  since  complex  flight  trials  involving  multi  target 
engagements  are  not  required.  Testing  takes  place  within  the  confines  of  the  laboratory  with  all  its 
advantages  of  test  control  and  repeatability. 

Radar  Simulation 


In  order  to  support  a  continued  flight  test  programme  it  is  necessary  that  the  aircraft  take 
highest  priority  on  equipment  allocation.  There  are  occasions,  therefore,  when  the  rig  ha£  to  release 
equipment  to  the  aircraft.  In  addition  it  is  not  always  cost  effective  to  dedicate  a  fully 
operational  radar  system  to  rig  work  alone.  Since  rig  work  on  weapon  system  development  is  dependent 
on  a  source  of  target  data  it  was  .thought  wise  to  have  available  an  alternative  source  other  than  a 
complete  radar  system.  This  has  been  achieved,  to  great  effect,  by  utilising  a  real  radar  data 
processing  unit  in  combination  with  radar  system  simulation.  In  retaining  the  real  radar  data 
processor  both  the  radar  system  Interface  with  the  rest  of  the  avionics  and  the  radar  system  software 
are  preserved.  The  target  data  output  by  the  model  interfaces  directly  with  the  radar  simulation,  the 
RF  target  generator  unit  is  not  required. 

Therefore  with  or  without  the  aircraft  radar  equipment  on  the  rig,  weapon  aiming  system 
development  can  continue  uninterrupted. 

Simulation  Validation 


As  described  previously  the  avionics  rig  is  subject  to  the  same  configuration  controls  as  the 
aircraft.  This  control  extends  to  the  facilities  used  on  the  rig  including  the  system  simulations. 
These  simulations  which  are  used  to  clear  aircraft  equipment  are  therefore  validated  before  use 
through  eatabliahed  quality  assurance  procedures. 
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5.  DYNAMIC  MODES  OF  OPERATION 


The  process  of  'flying'  the  rig  is  executed  either  manually  or  automatically,  depending  on  the 
nature  of  the  test  requirements.  In  the  automatic  modes  the  rig  aircrafts  flight  profile  is  derived 
from  either  the  system  modelling  process  or  from  aircraft  flight  trials  data. 

Manual  Operation 

This  is  the  main  mode  of  operation  which  covers  the  bulk  of  system  development  testing.  The 
simulation  system  is  initialised  with  rig  and  target  aircraft  data.  The  crew  then  fly  the  rig 
aircraft  via  the  pilots  cockpit  controls  and  operate  the  avionics  system  for  the  particular  test  in 
progress.  Data  logging,  which  will  have  been  pre-defined,  can  be  controlled  to  record  the  relevant 
phase  or  phases  of  the  flight  as  the  test  progresses.  The  trajectories  of  the  rig  aircraft  and  the 
targets  can  also  be  recorded  to  provide  a  source  of  data  with  which  to  drive  the  avionics  system 
model.  This  enables  the  test  to  be  rerun  on  the  model  which  simplifies  and  reduces  the  cost  of  the 
analysis  process  since  a  direct  comparison  between  the  rig  and  model  outputs  is  possible. 

For  the  majority  of  the  time  the  rig  'aircraft'  crew  is  made  up  from  the  test  engineers 
themselves.  They  are  able  to  fly  the  avionics  system  and  operate  the  data  acquisition/simulation 
processes  as  necessary.  Thus  if  a  system  abnormality  occurs  in  flight  the  rig  aircraft  can  be  frozen 
whilst  investigation  of  current  data  values  takes  place. 

The  manual  mode  of  operation  is  also  of  great  value  to  actual  aircrew.  They  are  able  to 
familiarise  themselves  with  system  operation  by  rehearsing  the  planned  trials  before  flying  the  real 
aircraft.  Post  flight  comments  can  also  be  illustrated  on  the  real  equipment  by  aircrew 
demonstrations  to  development  engineers. 

Automatic  Operation  1 

Certain  system  development  tests  demand  specific  aircraft/ target  scenarios  to  be  executed.  These 
scenarios  are  usually  the  result  of  extensive  system  modelling  work  which  has  preceeded  rig  testing, 
therefore,  the  avionic  system  response  has  already  been  predicted.  From  this  modelling  process  a  rig 
forcing  tape  is  produced  that  contains  the  necessary  driving  signals  to  fly  both  the  rig  aircraft  and 
the  targets.  Thus  the  pilots  flying  task  is  removed  and  the  rig  aircraft  flys  a  predetermined  fixed 
profile  automatically. 

The  forcing  tape  is  run  on  the  rig  DASS  and  the  flight  data  is  passed  directly  to  the  navigation 
sensor  simulation  thus  bypassing  the  aircraft  aerodynamic  model.  All  system  initialisation  data  is 
contained  on  the  tape  including  that  for  the  target  aircraft.  Although  the  rig  aircraft  and  the 
targets  respond  directly  to  the  data  on  the  forcing  tape,  the  avionics  system  itself  can  be  operated 
as  required.  Therefore  the  same  scenario  can  be  flown  repeatedly  but  with  a  different  weapon  aiming 
mode  in  operation  for  each  flight.  The  crew  have  complete  freedom  of  avionic  system  operation  in  this 
respect  it  is  just  the  aircraft  flight  profile  that  is  pre-determined.  Far  more  target  engagement 
scenarios  and  attack  profile  combinations  can  be  evaluated  in  this  way  than  could  ever  be  achieved  by 
using  the  real  aircraft. 

As  with  the  case  for  manua  operation  data  analysis  mainly  involves  matching  rig  recorded  data 
with  system  modelling  data  to  identify  disparities  between  the  two.  Inequalities  of  this  nature  are 
then  subjected  to  further  in  depth  analysis  or  additional  rig  tests. 

Rig  forcing  in  this  manner  is  the  means  by  which  the  system  performance,  predicted  by  the  model, 
is  compared  to  that  of  the  actual  aircraft  avionics  equipments.  Close  interaction  therefore  exists 
between  these  two  facilities  leading  to  a  more  accurate  and  representative  system  model  as  well  as 
avionic  system  validation. 

There  Is  a  further  mode  of  automatic  operation  which  differs  in  one  respect  only  and  that  Is  in 
the  source  of  the  forcing  data. 

Automatic  Operation  2 

The  second  mode  of  automatic  operation  brings  in  yet  another  element  of  the  development 
facilities  ie  the  aircraft. 

Suitable  recording  of  aircraft  data  during  actual  flight  testing  trials  represents  an  additional 
source  of  forcing  data  for  both  the  system  model  and  the  rig.  The  in-flight  data  has  to  be 
re-formatted  to  produce  the  necessary  forcing  tape  for  rig  use  but  the  data  values  remain  as  per 
aircraft.  Thus  it  is  possible  to  re-run  a  flight  trial  on  the  rig  should  flight  back  up  testing  be 
necessary.  The  actual  aircrew  can  be  used  to  operate  t’’  rig  avionics  system  as  they  did  during  the 
flight  trial.  Therefore  in-flight  problems  can  be  closely  examined  on  the  rig  under  representative 
operational  conditions  without  the  need  for  extra  flight  trials. 

Once  again  a  close  Interaction  exists  between  the  aircraft,  the  rig  and  the  system  model  and 
further  mutual  refinement  of  these  facilities  is  achleveable. 
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6.  ADVANTAGES  OF  THE  DYNAMIC  TESTING  APPROACH 


The  major  advantage  of  adopting  the  dynamic  testing  approach  on  the  avionics  development  rig  is 
one  of  cost  reduction,  rig  'flying'  time  costs  are  far  less  than  those  for  the  aircraft.  Reductions 
in  the  flight  test  programme  devoted  to  avionics  development  have  occurred  and  a  more  efective  use  of 
flight  testing  time  is  being  achieved.  These  points  are  all  illustrated  by  the  following  factors  : 

(1)  The  operational  clearance  of  the  avionics  system  to  the  aircraft  is  of  a  higher  standard 
and  is  more  precisely  defined.  Criticisms  of  the  system  operation  by  the  aircrew  now 
concentrate  on  moding  and  design  philosophy  as  opposed  to  operational  malfunctions 

(2)  A  greater  appreciation  of  the  actual  system  operational  capabilities  is  available  at  an 
earlier  stage  in  the  development  programme.  This  leads  to  improved  forward  planning  of  the 
flight  test  programme  to  maximise  the  data  gathering  process. 

(3)  Problems  that  do  arise  in  flight,  that  would  have  previously  required  extra  flying  time  in 
the  pursuit  of  the  solution,  can  now  be  addressed  on  the  rig.  We  have  at  our  disposal  a 
much  improved  flight  test  back  up  facility. 

(4)  Pre-flight,  system  operational  demonstration  to  aircrew  on  the  rig  is  more  exte  isive  and 
meaningful.  Thus,  incidents  during  flight  due  to  'finger  trouble'  or  system  operation 
unfamiliarity  are  reduced. 

(5)  Post  flight  comments  by  aircrew  on  system  operation  particularly  those  on  cockpit  displays 
can  be  easily  illustrated  with  reference  to  demonstration  on  the  rig.  This  leads  to  a 
better  understanding  and  interpretation  of  the  comments  by  the  development  engineers. 

Additional  advantages  are  also  apparent  that  do  not  directly  affect  the  flight  test  programme  but 
are  still  worth  mentioning  : 

The  engineers  working  on  the  rig  enjoy  dynamic  testing  and  the  ability  to  'fly'  the  system. 

Their  lntetest  and  appreciation  of  the  whole  system  is  increased  as  is  their  commitment  to  the 
development  task.  This  is  accompanied  by  improved  reporting  and  problem  area  identification. 

An  improved  standard  of  aircraft  groundcrew  training  is  being  achieved  by  utilising  the  dynamic 
capabilities  of  the  rig. 

The  use  of  the  rig  as  a  demonstrator  of  the  system  operational  facilities  to  potential  customers 
has  been  greatly  enhanced. 

7.  FUTURE  DEVELOPMENTS 


The  main  trend  of  future  developments  will  undoubtedly  have  as  their  objective  a  further 
reduction  in  system  development  costs.  This  will  be  achieved  by  accommodating  more  of  the  avionics 
content  of  the  flight  test  programme  on  the  rig.  Hence,  this  programme  will  be  reduced  to  a  series  of 
system  operational  confirmation  and  validation  flights.  It  will  also  be  the  aim  to  reduce  the  rig 
testing  timescales  to  speed  up  the  system  clearance  to  the  aircraft.  One  aspect  that  will  contribute 
significantly  to  this  aim  is  the  automation  of  the  data  reduction  and  analysis  process.  The  rig  and 
the  system  model  could  be  run  in  parallel  at  the  same  time  from  the  Bame  forcing  data.  The  two  sets 
of  results  would  be  continually  compared  and  the  error  signals  output  ss  the  end  product.  Signal 
disparities  would  therefore  be  available  at  the  end  of  the  test  run. 

To  assist  in  future  systems  design  the  rigs  themselves  can  be  linked  so  that  one  rig  aircraft 
system  is  flown  against  another.  Using  the  Tornado  IDS  rig  as  a  target  aircraft  for  the  Tornado  F  Mk  2 
system  has  already  been  discussed.  Thiough  this  development,  combat  situations  would  be  executed  on 
the  rigs  using  the  full  avionics  systems  of  both  aircraft  plus  additional  simulations.  Further 
studies  of  system  effectiveness,  optimum  system  ueage  and  crew  workloads  could  be  accommodated. 

One  aspect  of  system  operation  that  will  soon  be  studied  with  little  or  no  modification  to  the 
existing  facilities  is  that  of  reversionary  modes.  It  is  a  fairly  simple  matter  to  intentionally 
cause  avionic  equipment  failures  during  flight  on  the  rig.  The  consequences  of  single  and  multiple 
equipment  failures  can  thuB  be  examined  . ithout  putting  the  aircraft  at  risk. 

8.  CONCLUSIONS 


This  paper  has  introduced  the  philosophy  adopted  at  British  Aerospace  Warton  for  the  pre-flight 
ground  testing  of  avionics  systems. 

Particular  reference  has  been  made  to  the  Tornado  F  Mk  2  avionics  development  rig  and  its  ability 
to  simulate  flight  through  the  use  of  dynamic  testing  techniques.  These  techniques,  involving  an 
integrated  approach  to  the  use  of  the  development  facilities  availrble  and  a  growth  in  the  use  of 
computing,  have  had  a  significant  effect  on  reducing  the  overall  system  development  costs  due  to  : 

(1)  A  reduction  in  the  flying  hours  devoted  to  avionic  system  developments 

(2)  More  effective  use  of  the  flight  testing  time  available. 

The  success  of  this  approach  has  been  such  that  both  the  Tornado  IDS  and  Jaguar  rigs,  which 
preceeded  the  Tornado  F  Mk  2  rig,  have  now  been  uprated  to  facilitate  dynamic  testing.  The  impact  on 
these  projects  has  been  the  same  as  that  experienced  on  the  Tornado  F  Mk  2  project. 
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DISCUSSION 


K.F.Boecking,  Ge 

Do  you  use  the  rig  as  an  aid  for  avionics  development  only  or  do  you  use  it  for  simulation  also  (e.g.  aircraft  handling 
qualities  or  attack-profiles  etc.)? 

Author’s  Reply 

Aircraft  handling  testing  is  conducted  on  our  Flight  Controls  Rig  which  is  a  separate  facility  to  the  one  described 
in  the  paper.  The  flight  Control  Rig  is  used  to  test  and  verify  the  Autopilot  &  Flight  Director  and  command 
stability  augmentation  systems.  Attack  profiles,  however,  are  conducted  on  the  Avionic  Development  Rig  as  well  as 
Avionics  Systems  Development. 


J.O.Vaillancourt,  Ca 

(1)  How  many  rigs  do  you  manufacture  and  are  they  available  for  sale  to  the  aircraft  purchaser? 

(2)  Do  you  have  different  types  of  rigs  for  different  aircraft  versions? 

Author’s  Reply 

We  have  built  Avionics  Systems  Development  Rigs,  similar  to  that  described  ir.  the  paper,  for  Jaguar,  Jaguar  fly-by- 
wire  and  Tornado  IDS  aircraft.  In  addition  a  Flight  Controls  Rig  for  the  Tornado  IDS/ADV  aircraft  also  exists. 
The  Avionics  Rigs  are  to  accommodate  future  system  developments  for  a  particular  aircraft  or  aircraft  type.  We 
have  indeed  built  such  avionic  rigs  for  the  customer.  I.e.  the  RAF  have  a  Jaguar  rig  and  a  Tornado  IDS  rig.  These 
rigs  are  built  to  meet  the  specific  requirements  of  the  customer  and  are  manufactured  by  the  same  team  that 
produce  our  own  rigs. 
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14.Abstract 


These  Proceedings  include  the  41  papers  and  discussions  presented  at  the  45th  Symposium/ 
Meeting  of  the  AGARD  Avionics  Panel  held  in  Ottawa,  Ontario,  Canada,  1 8-22  April  1983. 
The  Keynote  Address,  Session  Summaries,  and  Technical  Evaluation  Report  provided 
respectively  the  challenge  for  the  Symposium,  summaries  of  the  sessions,  and  the  overall 
technical-scientific  assessment  of  the  Symposium  with  conclusions  and  recommendations. 

Modem  aircraft  weapon  systems  are  being  structured  with  more  interdependency  among 
subsystems.  In  order  to  realize  the  benefits  of  advanced  integration  while  achieving  the 
required  performance,  new  design  and  development  concepts  were  presented.  Sessions  were 
devoted  to  System  Design  Criteria,  Avionics  anc  Systems  State-of-the-Art,  System 
Development  Concepts,  and  System  Integration  and  Test. 
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